libosmscout-development — Talk about the development of libosmscout

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

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

Hi,

As Lukas pointed, the problem is with the DrawGround.

Next picture is just after DrawGroundTiles and before next Tile update.

[image: image.png]

The problem is that I pass the new center coords to the Draw function, but
the ground tile should be made for the old ones, before update.











On Mon, 3 Jan 2022 at 17:42, Lukáš Karas <luk...@ce...> wrote:

> Hi.
>
> Its looking like that canvas is not cleared before rendering and there is
> content from previous cycle... But it seems that DGI backend has
> MapPainterGDI::DrawGround implementation.
>
> Lukas
>
> Dne pondělí 3. ledna 2022 17:29:42 CET David Huelves Ramos napsal(a):
> > I think Artefacts are because the "Resize" method, that is the one
> intended
> > to delete the bitmap, doesn't do it, because the width and height are the
> > same.
> >
> > this would explain why at start all looks fine. But when Apply
> > movement/Zoom things go wrong.
> >
> > On Mon, 3 Jan 2022 at 13:17, Tim Teulings <ti...@fr...> wrote:
> > > Hello David,
> > >
> > > > I tried DumpData but don't know how to call it to check maps.
> > > >
> > > > I tried ".\DumpData <path-maps> -wo 0" but nothing happens.
> > >
> > > You pass it the directory for a map. Example:
> > >
> > > debug/DumpData/DumpData maps/arnsberg-regbez -n 6918523432
> > > Node {
> > >
> > >    OSM id: 6918523432
> > >    fileOffset: 3763186
> > >    type: highway_bus_stop
> > >
> > >    Name: Rauher Dorn
> > >
> > >    lat: 51.57214
> > >    lon: 7.46435
> > >
> > > }
> > >
> > > where arnsberg-regbez is the map directory created during import using
> > > libosmscout of a *.pbf file.
> > >
> > > --
> > > Gruß...
> > >
> > >     Tim
> > >
> > > _______________________________________________
> > > Libosmscout-development mailing list
> > > Lib...@li...
> > > https://lists.sourceforge.net/lists/listinfo/libosmscout-development

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

[Lukáš K. <luk...@ce...>]

Hi. 

Its looking like that canvas is not cleared before rendering and there is 
content from previous cycle... But it seems that DGI backend has 
MapPainterGDI::DrawGround implementation.

Lukas

Dne pondělí 3. ledna 2022 17:29:42 CET David Huelves Ramos napsal(a):
> I think Artefacts are because the "Resize" method, that is the one intended
> to delete the bitmap, doesn't do it, because the width and height are the
> same.
> 
> this would explain why at start all looks fine. But when Apply
> movement/Zoom things go wrong.
> 
> On Mon, 3 Jan 2022 at 13:17, Tim Teulings <ti...@fr...> wrote:
> > Hello David,
> > 
> > > I tried DumpData but don't know how to call it to check maps.
> > > 
> > > I tried ".\DumpData <path-maps> -wo 0" but nothing happens.
> > 
> > You pass it the directory for a map. Example:
> > 
> > debug/DumpData/DumpData maps/arnsberg-regbez -n 6918523432
> > Node {
> > 
> >    OSM id: 6918523432
> >    fileOffset: 3763186
> >    type: highway_bus_stop
> >    
> >    Name: Rauher Dorn
> >    
> >    lat: 51.57214
> >    lon: 7.46435
> > 
> > }
> > 
> > where arnsberg-regbez is the map directory created during import using
> > libosmscout of a *.pbf file.
> > 
> > --
> > Gruß...
> > 
> >     Tim
> > 
> > _______________________________________________
> > Libosmscout-development mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libosmscout-development

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

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

I think Artefacts are because the "Resize" method, that is the one intended
to delete the bitmap, doesn't do it, because the width and height are the
same.

this would explain why at start all looks fine. But when Apply
movement/Zoom things go wrong.

On Mon, 3 Jan 2022 at 13:17, Tim Teulings <ti...@fr...> wrote:

> Hello David,
>
> > I tried DumpData but don't know how to call it to check maps.
> >
> > I tried ".\DumpData <path-maps> -wo 0" but nothing happens.
> You pass it the directory for a map. Example:
>
> debug/DumpData/DumpData maps/arnsberg-regbez -n 6918523432
> Node {
>    OSM id: 6918523432
>    fileOffset: 3763186
>    type: highway_bus_stop
>
>    Name: Rauher Dorn
>
>    lat: 51.57214
>    lon: 7.46435
> }
>
> where arnsberg-regbez is the map directory created during import using
> libosmscout of a *.pbf file.
>
> --
> Gruß...
>     Tim
>
>
>
> _______________________________________________
> Libosmscout-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>

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

[Tim T. <ti...@fr...>]

Hello David,

> I tried DumpData but don't know how to call it to check maps.
> 
> I tried ".\DumpData <path-maps> -wo 0" but nothing happens.
You pass it the directory for a map. Example:

debug/DumpData/DumpData maps/arnsberg-regbez -n 6918523432
Node {
   OSM id: 6918523432
   fileOffset: 3763186
   type: highway_bus_stop

   Name: Rauher Dorn

   lat: 51.57214
   lon: 7.46435
}

where arnsberg-regbez is the map directory created during import using 
libosmscout of a *.pbf file.

-- 
Gruß...
    Tim

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

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

OSM Map VS libosmscout

OSM Map
[image: image.png]
Libosmscout (moving the center to redraw tile)
[image: image.png]
 BUT if I just start DrawGDI at the same spot: (everything looks fine). So
I think it has to be with the redraw (but don't know why). I just change
coord center, even if I zoom in-out happens.
[image: image.png]

This is a comparison for Online OSM vs libosmscout. The artefacts make it
inservible... :(
but I don't know where to start checking.




On Mon, 3 Jan 2022 at 09:35, David Huelves Ramos <dav...@gm...>
wrote:

> Hi,
>
> I tried DumpData but don't know how to call it to check maps.
>
> I tried ".\DumpData <path-maps> -wo 0" but nothing happens.
>
>
>
> On Sun, 2 Jan 2022 at 18:34, David Huelves Ramos <dav...@gm...>
> wrote:
>
>> Hi,
>>
>> I investigate more tomorrow.
>>
>> I'll report.
>>
>> Regards and thanks again.
>>
>> On Sun, 2 Jan 2022 at 17:43, Tim Teulings <ti...@fr...> wrote:
>>
>>> Hello David,
>>>
>>> it is very difficult to decide what went wrong. We know that the tiling
>>> approach sometimes creates artifacts (looks like parly drawn objects
>>> with rectangular cuts). But this seem to be much worse. I suggest to
>>> compare it witht he original online OSM map to spot the difference.
>>> Looks like possibly a few objects drive the render mad. Could even be a
>>> bad/different mapping that is not well handled.
>>>
>>> --
>>> Gruß...
>>>     Tim
>>>
>>>
>>>
>>> _______________________________________________
>>> Libosmscout-development mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>>
>>

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

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

Hi,

I tried DumpData but don't know how to call it to check maps.

I tried ".\DumpData <path-maps> -wo 0" but nothing happens.



On Sun, 2 Jan 2022 at 18:34, David Huelves Ramos <dav...@gm...>
wrote:

> Hi,
>
> I investigate more tomorrow.
>
> I'll report.
>
> Regards and thanks again.
>
> On Sun, 2 Jan 2022 at 17:43, Tim Teulings <ti...@fr...> wrote:
>
>> Hello David,
>>
>> it is very difficult to decide what went wrong. We know that the tiling
>> approach sometimes creates artifacts (looks like parly drawn objects
>> with rectangular cuts). But this seem to be much worse. I suggest to
>> compare it witht he original online OSM map to spot the difference.
>> Looks like possibly a few objects drive the render mad. Could even be a
>> bad/different mapping that is not well handled.
>>
>> --
>> Gruß...
>>     Tim
>>
>>
>>
>> _______________________________________________
>> Libosmscout-development mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>
>

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

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

Hi,

I investigate more tomorrow.

I'll report.

Regards and thanks again.

On Sun, 2 Jan 2022 at 17:43, Tim Teulings <ti...@fr...> wrote:

> Hello David,
>
> it is very difficult to decide what went wrong. We know that the tiling
> approach sometimes creates artifacts (looks like parly drawn objects
> with rectangular cuts). But this seem to be much worse. I suggest to
> compare it witht he original online OSM map to spot the difference.
> Looks like possibly a few objects drive the render mad. Could even be a
> bad/different mapping that is not well handled.
>
> --
> Gruß...
>     Tim
>
>
>
> _______________________________________________
> Libosmscout-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>

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

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

Hi Tim,

I didn't know a tool like that exists :). I'll check.

Thanks

On Sun, 2 Jan 2022 at 17:37, Tim Teulings <ti...@fr...> wrote:

> Hello David,
>
>  > Further investigation.... (These values, the ones that takes so much
>  > time to be rendered are wrong... as they point to infinite points....).
>
> why were there such strange values? Did you check the raw data in the
> database (via for example the DumpData tool)?
>
> If the GDI tries to draw very long lines (without any clipping) it makes
> sense that this might take long.
> --
> Gruß...
>     Tim
>
>
>
> _______________________________________________
> Libosmscout-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>

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

[Tim T. <ti...@fr...>]

Hello David,

it is very difficult to decide what went wrong. We know that the tiling 
approach sometimes creates artifacts (looks like parly drawn objects 
with rectangular cuts). But this seem to be much worse. I suggest to 
compare it witht he original online OSM map to spot the difference. 
Looks like possibly a few objects drive the render mad. Could even be a 
bad/different mapping that is not well handled.

-- 
Gruß...
    Tim

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

[Tim T. <ti...@fr...>]

Hello David,

 > Further investigation.... (These values, the ones that takes so much
 > time to be rendered are wrong... as they point to infinite points....).

why were there such strange values? Did you check the raw data in the 
database (via for example the DumpData tool)?

If the GDI tries to draw very long lines (without any clipping) it makes 
sense that this might take long.
-- 
Gruß...
    Tim

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

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

I added a few ago a message to catch mouse movement. If I use it in high
dense areas nothing seems to happen but In low dense areas I get these
artifacts....

[image: image.png]

Any Ideas?

I tested it with the actual libraries (map+mapgdi) and with the optimized I
made and nothing seems to change, so It was a previous error.




On Sun, 2 Jan 2022 at 12:36, David Huelves Ramos <dav...@gm...>
wrote:

> I Filtered these values and I get in debug mode less than 60msecs.
>
> I'm gonna try in release.
>
>
>
> On Sun, 2 Jan 2022 at 12:20, David Huelves Ramos <dav...@gm...>
> wrote:
>
>> Further investigation.... (These values, the ones that takes so much time
>> to be rendered are wrong... as they point to infinite points....).
>>
>> [image: image.png]
>>
>> On Sun, 2 Jan 2022 at 11:28, David Huelves Ramos <dav...@gm...>
>> wrote:
>>
>>> [image: image.png]
>>> Points mean the DrawLines Method from DrawPathCGI. I can't understand
>>> why these 2 calls to this function with only 2 elements each can spend so
>>> much time.....
>>> While DrawAreas that uses as you can see in the log more than 10000
>>> elements only spend 0.089ms in debug mode. Doing almost the same, Well
>>> DrawAreas draw polygons instead of lines.
>>>
>>> On Sat, 1 Jan 2022 at 22:58, David Huelves Ramos <
>>> dav...@gm...> wrote:
>>>
>>>> Hello,
>>>>
>>>> I found that  "pRender->m_pGraphics->DrawLines" is the slowest function
>>>> in particular cases. a that + news+deletes is what makes code drawing-ways
>>>> slow.
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>> On Sat, 1 Jan 2022 at 19:46, David Huelves Ramos <
>>>> dav...@gm...> wrote:
>>>>
>>>>> I already modified the news-deletes to avoid them and only one at
>>>>> start is available but Drawways is still too slow... The big loop is not
>>>>> huge but I guess some of the items treatment is heavy....
>>>>>
>>>>> Continue investigating,
>>>>>
>>>>> On Sat, 1 Jan 2022 at 14:03, David Huelves Ramos <
>>>>> dav...@gm...> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> As I supposed the amount of news-deletes makes the GDI version Sooooo
>>>>>> slow.
>>>>>>
>>>>>> I have changed the DrawAreas method to calculate the máximun coords
>>>>>> an Area can have each Invalidate and things have sped up considerably.
>>>>>> I'll change also DrawWays in the same way and It will fly.
>>>>>>
>>>>>> Happy new year for all.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> On Fri, 31 Dec 2021 at 12:04, David Huelves Ramos <
>>>>>> dav...@gm...> wrote:
>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> DrawPath is still slow as It's a huge loop where each step needs to
>>>>>>> create and destroy an array of points. This Array can be created first and
>>>>>>> never deleted between all drawpath process if we keep the max space needed
>>>>>>> for the longest Way.
>>>>>>> And we manage the array with an index each time.
>>>>>>>
>>>>>>> Let's see what can I do :O
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, 31 Dec 2021 at 11:19, Tim Teulings <ti...@fr...> wrote:
>>>>>>>
>>>>>>>> Hello David,
>>>>>>>>
>>>>>>>> > There is also a bug in the m_Data member. As it is an array but
>>>>>>>> delete
>>>>>>>> > is not deleting the array just the pointer, leaving leaks each
>>>>>>>> addpoint
>>>>>>>> > I'll write back the modifications I made.
>>>>>>>>
>>>>>>>> Thanks for taking a more in deep look than me (my Development Setup
>>>>>>>> under Windows is currently limited).
>>>>>>>>
>>>>>>>> Of course we will accept any patch in result of your findings :-)
>>>>>>>> So do
>>>>>>>> not hesitate :-)
>>>>>>>>
>>>>>>>> --
>>>>>>>> Gruß...
>>>>>>>>     Tim
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Libosmscout-development mailing list
>>>>>>>> Lib...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>>>>>>>
>>>>>>>

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

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

I Filtered these values and I get in debug mode less than 60msecs.

I'm gonna try in release.



On Sun, 2 Jan 2022 at 12:20, David Huelves Ramos <dav...@gm...>
wrote:

> Further investigation.... (These values, the ones that takes so much time
> to be rendered are wrong... as they point to infinite points....).
>
> [image: image.png]
>
> On Sun, 2 Jan 2022 at 11:28, David Huelves Ramos <dav...@gm...>
> wrote:
>
>> [image: image.png]
>> Points mean the DrawLines Method from DrawPathCGI. I can't understand why
>> these 2 calls to this function with only 2 elements each can spend so much
>> time.....
>> While DrawAreas that uses as you can see in the log more than 10000
>> elements only spend 0.089ms in debug mode. Doing almost the same, Well
>> DrawAreas draw polygons instead of lines.
>>
>> On Sat, 1 Jan 2022 at 22:58, David Huelves Ramos <dav...@gm...>
>> wrote:
>>
>>> Hello,
>>>
>>> I found that  "pRender->m_pGraphics->DrawLines" is the slowest function
>>> in particular cases. a that + news+deletes is what makes code drawing-ways
>>> slow.
>>>
>>> Regards
>>>
>>>
>>>
>>> On Sat, 1 Jan 2022 at 19:46, David Huelves Ramos <
>>> dav...@gm...> wrote:
>>>
>>>> I already modified the news-deletes to avoid them and only one at start
>>>> is available but Drawways is still too slow... The big loop is not huge but
>>>> I guess some of the items treatment is heavy....
>>>>
>>>> Continue investigating,
>>>>
>>>> On Sat, 1 Jan 2022 at 14:03, David Huelves Ramos <
>>>> dav...@gm...> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> As I supposed the amount of news-deletes makes the GDI version Sooooo
>>>>> slow.
>>>>>
>>>>> I have changed the DrawAreas method to calculate the máximun coords an
>>>>> Area can have each Invalidate and things have sped up considerably.
>>>>> I'll change also DrawWays in the same way and It will fly.
>>>>>
>>>>> Happy new year for all.
>>>>>
>>>>> Regards
>>>>>
>>>>> On Fri, 31 Dec 2021 at 12:04, David Huelves Ramos <
>>>>> dav...@gm...> wrote:
>>>>>
>>>>>> Hello
>>>>>>
>>>>>> DrawPath is still slow as It's a huge loop where each step needs to
>>>>>> create and destroy an array of points. This Array can be created first and
>>>>>> never deleted between all drawpath process if we keep the max space needed
>>>>>> for the longest Way.
>>>>>> And we manage the array with an index each time.
>>>>>>
>>>>>> Let's see what can I do :O
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, 31 Dec 2021 at 11:19, Tim Teulings <ti...@fr...> wrote:
>>>>>>
>>>>>>> Hello David,
>>>>>>>
>>>>>>> > There is also a bug in the m_Data member. As it is an array but
>>>>>>> delete
>>>>>>> > is not deleting the array just the pointer, leaving leaks each
>>>>>>> addpoint
>>>>>>> > I'll write back the modifications I made.
>>>>>>>
>>>>>>> Thanks for taking a more in deep look than me (my Development Setup
>>>>>>> under Windows is currently limited).
>>>>>>>
>>>>>>> Of course we will accept any patch in result of your findings :-) So
>>>>>>> do
>>>>>>> not hesitate :-)
>>>>>>>
>>>>>>> --
>>>>>>> Gruß...
>>>>>>>     Tim
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Libosmscout-development mailing list
>>>>>>> Lib...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>>>>>>
>>>>>>

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

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

Further investigation.... (These values, the ones that takes so much time
to be rendered are wrong... as they point to infinite points....).

[image: image.png]

On Sun, 2 Jan 2022 at 11:28, David Huelves Ramos <dav...@gm...>
wrote:

> [image: image.png]
> Points mean the DrawLines Method from DrawPathCGI. I can't understand why
> these 2 calls to this function with only 2 elements each can spend so much
> time.....
> While DrawAreas that uses as you can see in the log more than 10000
> elements only spend 0.089ms in debug mode. Doing almost the same, Well
> DrawAreas draw polygons instead of lines.
>
> On Sat, 1 Jan 2022 at 22:58, David Huelves Ramos <dav...@gm...>
> wrote:
>
>> Hello,
>>
>> I found that  "pRender->m_pGraphics->DrawLines" is the slowest function
>> in particular cases. a that + news+deletes is what makes code drawing-ways
>> slow.
>>
>> Regards
>>
>>
>>
>> On Sat, 1 Jan 2022 at 19:46, David Huelves Ramos <dav...@gm...>
>> wrote:
>>
>>> I already modified the news-deletes to avoid them and only one at start
>>> is available but Drawways is still too slow... The big loop is not huge but
>>> I guess some of the items treatment is heavy....
>>>
>>> Continue investigating,
>>>
>>> On Sat, 1 Jan 2022 at 14:03, David Huelves Ramos <
>>> dav...@gm...> wrote:
>>>
>>>> Hello,
>>>>
>>>> As I supposed the amount of news-deletes makes the GDI version Sooooo
>>>> slow.
>>>>
>>>> I have changed the DrawAreas method to calculate the máximun coords an
>>>> Area can have each Invalidate and things have sped up considerably.
>>>> I'll change also DrawWays in the same way and It will fly.
>>>>
>>>> Happy new year for all.
>>>>
>>>> Regards
>>>>
>>>> On Fri, 31 Dec 2021 at 12:04, David Huelves Ramos <
>>>> dav...@gm...> wrote:
>>>>
>>>>> Hello
>>>>>
>>>>> DrawPath is still slow as It's a huge loop where each step needs to
>>>>> create and destroy an array of points. This Array can be created first and
>>>>> never deleted between all drawpath process if we keep the max space needed
>>>>> for the longest Way.
>>>>> And we manage the array with an index each time.
>>>>>
>>>>> Let's see what can I do :O
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 31 Dec 2021 at 11:19, Tim Teulings <ti...@fr...> wrote:
>>>>>
>>>>>> Hello David,
>>>>>>
>>>>>> > There is also a bug in the m_Data member. As it is an array but
>>>>>> delete
>>>>>> > is not deleting the array just the pointer, leaving leaks each
>>>>>> addpoint
>>>>>> > I'll write back the modifications I made.
>>>>>>
>>>>>> Thanks for taking a more in deep look than me (my Development Setup
>>>>>> under Windows is currently limited).
>>>>>>
>>>>>> Of course we will accept any patch in result of your findings :-) So
>>>>>> do
>>>>>> not hesitate :-)
>>>>>>
>>>>>> --
>>>>>> Gruß...
>>>>>>     Tim
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Libosmscout-development mailing list
>>>>>> Lib...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>>>>>
>>>>>

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

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

[image: image.png]
Points mean the DrawLines Method from DrawPathCGI. I can't understand why
these 2 calls to this function with only 2 elements each can spend so much
time.....
While DrawAreas that uses as you can see in the log more than 10000
elements only spend 0.089ms in debug mode. Doing almost the same, Well
DrawAreas draw polygons instead of lines.

On Sat, 1 Jan 2022 at 22:58, David Huelves Ramos <dav...@gm...>
wrote:

> Hello,
>
> I found that  "pRender->m_pGraphics->DrawLines" is the slowest function in
> particular cases. a that + news+deletes is what makes code drawing-ways
> slow.
>
> Regards
>
>
>
> On Sat, 1 Jan 2022 at 19:46, David Huelves Ramos <dav...@gm...>
> wrote:
>
>> I already modified the news-deletes to avoid them and only one at start
>> is available but Drawways is still too slow... The big loop is not huge but
>> I guess some of the items treatment is heavy....
>>
>> Continue investigating,
>>
>> On Sat, 1 Jan 2022 at 14:03, David Huelves Ramos <dav...@gm...>
>> wrote:
>>
>>> Hello,
>>>
>>> As I supposed the amount of news-deletes makes the GDI version Sooooo
>>> slow.
>>>
>>> I have changed the DrawAreas method to calculate the máximun coords an
>>> Area can have each Invalidate and things have sped up considerably.
>>> I'll change also DrawWays in the same way and It will fly.
>>>
>>> Happy new year for all.
>>>
>>> Regards
>>>
>>> On Fri, 31 Dec 2021 at 12:04, David Huelves Ramos <
>>> dav...@gm...> wrote:
>>>
>>>> Hello
>>>>
>>>> DrawPath is still slow as It's a huge loop where each step needs to
>>>> create and destroy an array of points. This Array can be created first and
>>>> never deleted between all drawpath process if we keep the max space needed
>>>> for the longest Way.
>>>> And we manage the array with an index each time.
>>>>
>>>> Let's see what can I do :O
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, 31 Dec 2021 at 11:19, Tim Teulings <ti...@fr...> wrote:
>>>>
>>>>> Hello David,
>>>>>
>>>>> > There is also a bug in the m_Data member. As it is an array but
>>>>> delete
>>>>> > is not deleting the array just the pointer, leaving leaks each
>>>>> addpoint
>>>>> > I'll write back the modifications I made.
>>>>>
>>>>> Thanks for taking a more in deep look than me (my Development Setup
>>>>> under Windows is currently limited).
>>>>>
>>>>> Of course we will accept any patch in result of your findings :-) So
>>>>> do
>>>>> not hesitate :-)
>>>>>
>>>>> --
>>>>> Gruß...
>>>>>     Tim
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Libosmscout-development mailing list
>>>>> Lib...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>>>>
>>>>

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

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

Hello,

I found that  "pRender->m_pGraphics->DrawLines" is the slowest function in
particular cases. a that + news+deletes is what makes code drawing-ways
slow.

Regards



On Sat, 1 Jan 2022 at 19:46, David Huelves Ramos <dav...@gm...>
wrote:

> I already modified the news-deletes to avoid them and only one at start is
> available but Drawways is still too slow... The big loop is not huge but I
> guess some of the items treatment is heavy....
>
> Continue investigating,
>
> On Sat, 1 Jan 2022 at 14:03, David Huelves Ramos <dav...@gm...>
> wrote:
>
>> Hello,
>>
>> As I supposed the amount of news-deletes makes the GDI version Sooooo
>> slow.
>>
>> I have changed the DrawAreas method to calculate the máximun coords an
>> Area can have each Invalidate and things have sped up considerably.
>> I'll change also DrawWays in the same way and It will fly.
>>
>> Happy new year for all.
>>
>> Regards
>>
>> On Fri, 31 Dec 2021 at 12:04, David Huelves Ramos <
>> dav...@gm...> wrote:
>>
>>> Hello
>>>
>>> DrawPath is still slow as It's a huge loop where each step needs to
>>> create and destroy an array of points. This Array can be created first and
>>> never deleted between all drawpath process if we keep the max space needed
>>> for the longest Way.
>>> And we manage the array with an index each time.
>>>
>>> Let's see what can I do :O
>>>
>>>
>>>
>>>
>>> On Fri, 31 Dec 2021 at 11:19, Tim Teulings <ti...@fr...> wrote:
>>>
>>>> Hello David,
>>>>
>>>> > There is also a bug in the m_Data member. As it is an array but
>>>> delete
>>>> > is not deleting the array just the pointer, leaving leaks each
>>>> addpoint
>>>> > I'll write back the modifications I made.
>>>>
>>>> Thanks for taking a more in deep look than me (my Development Setup
>>>> under Windows is currently limited).
>>>>
>>>> Of course we will accept any patch in result of your findings :-) So do
>>>> not hesitate :-)
>>>>
>>>> --
>>>> Gruß...
>>>>     Tim
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Libosmscout-development mailing list
>>>> Lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>>>
>>>

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

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

I already modified the news-deletes to avoid them and only one at start is
available but Drawways is still too slow... The big loop is not huge but I
guess some of the items treatment is heavy....

Continue investigating,

On Sat, 1 Jan 2022 at 14:03, David Huelves Ramos <dav...@gm...>
wrote:

> Hello,
>
> As I supposed the amount of news-deletes makes the GDI version Sooooo
> slow.
>
> I have changed the DrawAreas method to calculate the máximun coords an
> Area can have each Invalidate and things have sped up considerably.
> I'll change also DrawWays in the same way and It will fly.
>
> Happy new year for all.
>
> Regards
>
> On Fri, 31 Dec 2021 at 12:04, David Huelves Ramos <dav...@gm...>
> wrote:
>
>> Hello
>>
>> DrawPath is still slow as It's a huge loop where each step needs to
>> create and destroy an array of points. This Array can be created first and
>> never deleted between all drawpath process if we keep the max space needed
>> for the longest Way.
>> And we manage the array with an index each time.
>>
>> Let's see what can I do :O
>>
>>
>>
>>
>> On Fri, 31 Dec 2021 at 11:19, Tim Teulings <ti...@fr...> wrote:
>>
>>> Hello David,
>>>
>>> > There is also a bug in the m_Data member. As it is an array but delete
>>> > is not deleting the array just the pointer, leaving leaks each addpoint
>>> > I'll write back the modifications I made.
>>>
>>> Thanks for taking a more in deep look than me (my Development Setup
>>> under Windows is currently limited).
>>>
>>> Of course we will accept any patch in result of your findings :-) So do
>>> not hesitate :-)
>>>
>>> --
>>> Gruß...
>>>     Tim
>>>
>>>
>>>
>>> _______________________________________________
>>> Libosmscout-development mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>>
>>

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

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

Hello,

As I supposed the amount of news-deletes makes the GDI version Sooooo slow.

I have changed the DrawAreas method to calculate the máximun coords an Area
can have each Invalidate and things have sped up considerably.
I'll change also DrawWays in the same way and It will fly.

Happy new year for all.

Regards

On Fri, 31 Dec 2021 at 12:04, David Huelves Ramos <dav...@gm...>
wrote:

> Hello
>
> DrawPath is still slow as It's a huge loop where each step needs to create
> and destroy an array of points. This Array can be created first and never
> deleted between all drawpath process if we keep the max space needed for
> the longest Way.
> And we manage the array with an index each time.
>
> Let's see what can I do :O
>
>
>
>
> On Fri, 31 Dec 2021 at 11:19, Tim Teulings <ti...@fr...> wrote:
>
>> Hello David,
>>
>> > There is also a bug in the m_Data member. As it is an array but delete
>> > is not deleting the array just the pointer, leaving leaks each addpoint
>> > I'll write back the modifications I made.
>>
>> Thanks for taking a more in deep look than me (my Development Setup
>> under Windows is currently limited).
>>
>> Of course we will accept any patch in result of your findings :-) So do
>> not hesitate :-)
>>
>> --
>> Gruß...
>>     Tim
>>
>>
>>
>> _______________________________________________
>> Libosmscout-development mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>
>

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

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

Hello

DrawPath is still slow as It's a huge loop where each step needs to create
and destroy an array of points. This Array can be created first and never
deleted between all drawpath process if we keep the max space needed for
the longest Way.
And we manage the array with an index each time.

Let's see what can I do :O




On Fri, 31 Dec 2021 at 11:19, Tim Teulings <ti...@fr...> wrote:

> Hello David,
>
> > There is also a bug in the m_Data member. As it is an array but delete
> > is not deleting the array just the pointer, leaving leaks each addpoint
> > I'll write back the modifications I made.
>
> Thanks for taking a more in deep look than me (my Development Setup
> under Windows is currently limited).
>
> Of course we will accept any patch in result of your findings :-) So do
> not hesitate :-)
>
> --
> Gruß...
>     Tim
>
>
>
> _______________________________________________
> Libosmscout-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>

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

[Tim T. <ti...@fr...>]

Hello David,

> There is also a bug in the m_Data member. As it is an array but delete 
> is not deleting the array just the pointer, leaving leaks each addpoint
> I'll write back the modifications I made.

Thanks for taking a more in deep look than me (my Development Setup 
under Windows is currently limited).

Of course we will accept any patch in result of your findings :-) So do 
not hesitate :-)

-- 
Gruß...
    Tim

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

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

There is also a bug in the m_Data member. As it is an array but delete is
not deleting the array just the pointer, leaving leaks each addpoint
I'll write back the modifications I made.

On Fri, 31 Dec 2021 at 08:47, David Huelves Ramos <dav...@gm...>
wrote:

> Hello,
>
> There is another point it has to be optimised (Addpoint method) it uses
> new's and moves each time a point is added. But in all the call functions
> we know how many points are going to be created as they are created in a
> loop from a to b.
> The allocation can be made before adding each point, this way we don't
> need to allocate mem for each point neither we have to move for each all
> the already stored data.
>
> for example:
> [image: image.png]
>
> Addpoint code: (allocation in red, movement in blue).
> [image: image.png]
>
> I'm gonna try
>
>
> On Thu, 30 Dec 2021 at 17:44, Tim Teulings <ti...@fr...> wrote:
>
>> Hello David,
>>
>> > I'll check first the CPen changes and then doblebuffer the demo to make
>>
>> builds finished, my changes are now in master.
>>
>> > things smoother (moving and zooming in and out).
>>
>> As the raw drawing speed should not be a problem, I assume that this
>> will improve performance.
>>
>> Keep an eye on "rendering action" being generated faster than getting
>> processed (by dropping pending actions, if an action is already in
>> process/queued). Lukas can like give some conceptional hints.
>>
>> > As soon as I get results I'll let you know
>> That will be helpful to keep my curiosity under control :-)
>>
>> --
>> Gruß...
>>     Tim
>>
>>
>>
>> _______________________________________________
>> Libosmscout-development mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>
>

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

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

Hello,

There is another point it has to be optimised (Addpoint method) it uses
new's and moves each time a point is added. But in all the call functions
we know how many points are going to be created as they are created in a
loop from a to b.
The allocation can be made before adding each point, this way we don't need
to allocate mem for each point neither we have to move for each all the
already stored data.

for example:
[image: image.png]

Addpoint code: (allocation in red, movement in blue).
[image: image.png]

I'm gonna try


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

> Hello David,
>
> > I'll check first the CPen changes and then doblebuffer the demo to make
>
> builds finished, my changes are now in master.
>
> > things smoother (moving and zooming in and out).
>
> As the raw drawing speed should not be a problem, I assume that this
> will improve performance.
>
> Keep an eye on "rendering action" being generated faster than getting
> processed (by dropping pending actions, if an action is already in
> process/queued). Lukas can like give some conceptional hints.
>
> > As soon as I get results I'll let you know
> That will be helpful to keep my curiosity under control :-)
>
> --
> Gruß...
>     Tim
>
>
>
> _______________________________________________
> Libosmscout-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>

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

[Tim T. <ti...@fr...>]

Hello David,

> I'll check first the CPen changes and then doblebuffer the demo to make 

builds finished, my changes are now in master.

> things smoother (moving and zooming in and out).

As the raw drawing speed should not be a problem, I assume that this 
will improve performance.

Keep an eye on "rendering action" being generated faster than getting 
processed (by dropping pending actions, if an action is already in 
process/queued). Lukas can like give some conceptional hints.

> As soon as I get results I'll let you know
That will be helpful to keep my curiosity under control :-)

-- 
Gruß...
    Tim

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
>

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

[Tim <ti...@fr...>]

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

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

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

Hi,

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.

Regards.

On Thu, 30 Dec 2021 at 13:19, Lukáš Karas <luk...@ce...> wrote:

> Hi David.
>
> Dne čtvrtek 30. prosince 2021 13:02:03 CET David Huelves Ramos napsal(a):
> > Getting the information.:
> >
> > [image: image.png]
> >
> > The bottleneck is drawing areas + drawing ways.
> >
> > Zoom in -> increments drawingways calculation time
> > Zoom out -> increments DrawingAreas calculation time.
> >
> > Both functions are a loop that is using just 1 thread from 1 processor.
> It
> > can be as all the loops implemented using Parallelism...
>
> It depends if GDI drawing methods allows parallel access. It is not
> supported
> in drawing libraries usually... Did you try to run profiler to see where
> the
> time is spend? If it is in GDI or osmscout...
>
> Lukas
>
> > On Thu, 30 Dec 2021 at 12:25, David Huelves Ramos <
> dav...@gm...>
> >
> > wrote:
> > > Hello,
> > >
> > > After googling a little this does the trick:
> > >
> > > [image: image.png]
> > >
> > > Now I get a console opened with cout/cerr redirected to it.
> > >
> > > On Thu, 30 Dec 2021 at 11:12, Tim Teulings <ti...@fr...> wrote:
> > >> Hi David,
> > >>
> > >> > Any Ideas?
> > >>
> > >> That should work. Is this possibly a Windows specifica? Is your
> > >> application linked as desktop or console application (WinMain vs.
> Main)?
> > >>
> > >> Do you see logs from the demo appliacations?
> > >>
> > >> --
> > >> Gruß...
> > >>
> > >>     Tim
> > >>
> > >> _______________________________________________
> > >> Libosmscout-development mailing list
> > >> Lib...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/libosmscout-development