kicad-developers team mailing list archive

[Maciej Suminski <maciej.suminski@xxxxxxx>]

Hi Chris,

Are you sure this is really needed? GAL is also used in other dialogs,
such as footprint browser or pad properties editor, and they do not seem
to take a lot of time to load. What is the initialization time we are
speaking about?

Anyway, if you are determined to optimize it, it is only a win for
everyone. I do not think we have ever tried keeping a GAL instance
without showing it, but IMHO it should be possible. OpenGL GAL/Linux
combination might be whining if you start rendering when the window is
not visible, but you may simply call DRAW_PANEL_GAL::StopDrawing() and
DRAW_PANEL_GAL::StartDrawing() as necessary.

Regarding rendering to memory, it actually happens behind the scenes.
For Cairo the memory is easily accesible (CAIRO_GAL::wxOutput,
CAIRO_GAL::bitmapBuffer). OpenGL renders most of the objects (grid is an
exception) to a framebuffer. Admitted, this is GPU memory, but it might
be read using glReadPixels().

Regards,
Orson

On 03/09/2017 08:27 PM, Chris Pavlina wrote:
> I'm trying to speed up my new component selector, since the previous one
> loaded and searched so quickly. I don't want a serious efficiency
> regression in one of the most used dialogs in eeschema.
> 
> Since optimizing the column sizing cache and data sorting, the slowest
> part is now loading FOOTPRINT_PREVIEW_PANEL, which has to initialize a
> GAL.
> 
> Tom/Orson/anyone else who knows GAL - can you think of a reasonable way
> to either speed up the initialization or retain an initialized copy
> between dialog invocations? I'm thinking about just keeping the dialog
> in memory all the time and hiding it when not in use instead of
> destroying and reinstantiating it - will this cause any problems with
> GAL no longer having something to draw to? (Bear in mind I'm unfamiliar
> with both GAL and how wxWidgets handles graphics here.)
> 
> If it provides any relevant information, I'm currently forcing Cairo
> mode in the component selector, to avoid having to deal with graphics
> support in a simple dialog (since drawing efficiency is not required).
>