kicad-developers team mailing list archive
Mailing list archive
Re: [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
On 12/14/2010 11:34 AM, jean-pierre charras wrote:
> Le 14/12/2010 17:06, Dick Hollenbeck a écrit :
>> On 12/14/2010 09:38 AM, Lorenzo Marcantonio wrote:
>>> On Tue, 14 Dec 2010, Dick Hollenbeck wrote:
>>>> I had a cathartic moment this weekend when the BLIT operations under wxwidgets on
>>>> linux flunked in the extreme.
>>>> I don't yet know what the better alternative is yet, just know we need one. For
>>>> gerbview, cairo and pixman are in my scope, and some research can be put into
>>>> techiques in gerbv and its graphical foundations, which I think are cairo and pixman.
>>> In my experience cairo is slower than anything I've seen (maybe even
>>> a Java2D would be faster).
>> Well you obviously did not recompile the latest gerbview with the patch that was
>> discussed Sunday night.
>> 20 seconds to update 12 gerver layers or so, on a super fast computer.
>> cairo is NOT the slowest. Besides, current testing should speak louder than past
>> experiences. I don't have an opinion yet on what is best for us. I just KNOW it aint
>> what we are using.
>>> Look at gerbv in cairo mode to get an idea.
>>> pixman looks more promising but I've no experience on it.
> For info: I spent some hours to test latest Gerbview, under Linux Ubuntu 10.10 , Windows XP and Vista.
> I used a 10 layers very large board (9500 pads/vias, 27000 track segments, a lot of copper areas)
> on my computer (a very common and low cost PC with a basic graphic card)with a single 1200x1000 pixels monitor.
> I do not have any speed issues:
> The new Gerbview is faster than the old version (at least as fast as Gerbv on my computer).
> The copy mode is roughly as fast as the or mode.
> When Gerbview is full screen, it takes about 1 second to redraw the screen (less than pcbnew to redraw the board).
> So "20 seconds to update 12 gerver layers or so, on a super fast computer" could be due to an other problem,
> even with monitor that have more pixels than mine.
> Having said this, I think if you are motivated to work on a new graphic alternative using the experimental Torsten's work,
> this is a *very good* news.
> I do not know if cairo or an other tool is faster or not.
> The answer will come from tests with very large boards on a lot of different computers and OS.
> But we can find a lot of enhancements (anti aliasing, better and more powerful graphic primitives ...)
> One of most important issues with the current wxDC implementation is the fact one cannot have a scaling factor for graphic texts.
> This is the main reason why Eeschema does not use usual fonts.
> Cairo is a candidate, but have also a look to sfml2:
> Developers are actively working on it.
> It is multi platform.
> It use currently cmake.
> It is small.
> It could be an other serious candidate.
Thanks for the discussion on gerbview.
1920 x 1200 = 2304000 pixels
--------------------------------- = 1.92
1200 x 1000 = 1200000 pixel
Yes, it seems you are correct, the area difference is no explanation for this large
difference in blit "mask with AND" mode.
So the question is, how many users will find themselves with the same problem? Hard
to answer if we don't know the reason for the problem.
gerbv is MUCH faster on my computer than the latest gerbview using "mask with AND".
However, using blit OR mode, gerbview is faster than gerbv.
If we can get that button in there to toggle the mode, perhaps we can simply postpone
solving the blit "mask with AND" question.
Also, thanks for your thoughts on the graphics subsystem.
Actually writing some bit of new code for Torsten's API will provide us with a lot of
observations. If the API is sound, most anything can be tucked underneath it.
After all, it is a GAL.
As far as speed goes, we may not get a good read on the speed until something more
demanding is done with it, like a gerbview or pcbnew. EESCHEMA would ask relatively
little of the GAL.