Re: [Libosmscout-development] GDI drawing Performance Under Windows

[David H. R. <dav...@gm...>]

Hi,

Sure,

I was talking without the hole picture of it.

I'll check first the CPen changes and then doblebuffer the demo to make
things smoother (moving and zooming in and out).

As soon as I get results I'll let you know

regards.


On Thu, 30 Dec 2021 at 17:25, Tim <ti...@fr...> wrote:

> Hello David,
>
> > Well I was talking about the generic MapPaint library.
> >
> > Every DrawArea/DrawWay loops for all areas/ways available. I think they
> > don't have any relationship between them so the loop can me split in the
> > computer processors to speed things up. Also GDI itself could be speed
> > up as Tim says.
>
> Note also that there is an inherent order in the things drawn.
>
> You draw ways on to of areas, and labels on top of all of them.
>
> Also ways have an (partial) order, thing of tunnels and bridges.
>
> There are still situations where parallel operations are possible, but
> not all stacks would support it (it depends where and how state is
> handled) and the question is, how much it improves rendering time.
>
> Not also that subtle changes to the actual rendering order on every
> render iteration during some zoom or pinch operation will make the map
> jump or cripple or similar.
>
> We spend some work to make sure that labels are stable rendered in such
> cases ;-)
>
> I'm in favor of experiments, but before big changes there should be a
> measurement that quantifies the possible improvement.
>
> --
> Gruß...
>      Tim
>
>
> _______________________________________________
> Libosmscout-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>