libosmscout-development — Talk about the development of libosmscout

[Libosmscout-development] Support for MODULE statement in OST and OSS files

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

Hello everbody,

due to a discussion in one of the osmin tickets I recently added a 
MODULE statement to the OST files.

This allows to split the currently monolithic files in to multiple 
smaller files. This way allow to reuse parts of the files in variants of 
import or style definitions, in effect for example allowing to think in 
"layers" or "groups".

The code was simple to add however is also simple in structure, 
currently error handling could be improved and also some more 
validations could be added (currently endless recursion for example is 
possible).
-- 
Gruß...
    Tim

Re: [Libosmscout-development] Incomplete maps conversion by Import utility

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

Hi :-)

> I installed MSYS/MinGW a week ago - especially for this task, so everything (tools and libraries) is of latest versions.

OK.

> For building I used cmake and ninja. Today I will try to build with meson, but I doubt this changes anything: different kinds of "make" utility is just a shell for launching the same tools (compilers and linkers) that do the real job; and  if executable is built incorrectly by them, unlikely it will exit quietly, much more probable it will end with some crash.

It helps us to exclude a possible problem. I will test the cmake build 
on my side in turn. I'm sure that cmake and meson in the end use 
possibly different options to build the software (at least nobody AFAIK 
tried to aline the options explicitely) so the is a small but >0 change 
that I would like to exclude (espeically afte rtrying to hunt pdf 
reading problems with the Visual Studio and vcpkg builds ;-)).

> Currently I have only a complete log of build process. But if this can help, also I will upload executable and necessary DLLs with embedded debug info.

One after the other.

>> With released version, you mean 1.1.0 from 2018? It is pretty old...
> 
> Yes, this one. By compiling it I was trying to investigate who is responsible for this problem - compiler/linker or sources.

I suggest you jump to the current state of the master branch and test again.

We fixed a number of inter-OS problems in the past, so the chance that 
thi is a bug in the older source version is rather high. Also you get a 
number of new features anyway :-)

Note, that we currently do not release regulary. Not because we do not 
have new features but because of releases and managing release is effort 
and likely would not help the maintainer of the depending applictions as 
much as it sounds.

As such using the last release is not as good as it sounds like. And 
there is much more development happing than a 4 year old release would 
suggest.

Of course I'm willing to make more releases if somebody offers help. 
Better use of github actions would make a release much more automatic 
and a "press of a button".

If you - as sombody new - see possible improvements to the documentation 
also do not hesitate to point at them :-)
-- 
Gruß...
    Tim

Re: [Libosmscout-development] Incomplete maps conversion by Import utility

[yup <yu...@bi...>]

19.04.2022 21:07, Tim wrote:
 
>> There are no any error messages neither from the operating system, nor from 
>> the utility itself, it just quietly finishes.
>> The last screen output from it is: "File 'maps\andorra\coord.dat' completely 
>> written" (I use andorra.osm.pbf from geofabrik.de because it is the smallest 
>> map file, but tried other maps too).
>>
>> However, when I compile the release version of the library with the same 
>> toolset, the "Import" utility works perfectly. So what is wrong with current 
>> versions? Is something broken in them?
> 
> I was not able to reproduce this. I have an up to date MSYS/MINGW (pacman -Suy), 
> I'M using the current maste rversion of the github repository. I use the meson 
> build (meson debug && cd debug && ninja) and the current geofabrik version of 
> andorra:[...]
> Do you also use the meson build or possibly cmake?

I installed MSYS/MinGW a week ago - especially for this task, so everything (tools and libraries) is of latest versions.
For building I used cmake and ninja. Today I will try to build with meson, but I doubt this changes anything: different kinds of "make" utility is just a shell for launching the same tools (compilers and linkers) that do the real job; and  if executable is built incorrectly by them, unlikely it will exit quietly, much more probable it will end with some crash.

> I have seen the effects you described using the Visual Studio Build. I assume in 
> the case of Visual Studio that the vcpkg builds are problematic (inconsistent 
> compiler options?).
There is no Visual Studio at this computer at all. Only Qt Creator with MinGW compiler and freshly added MSYS/MinGW. 
> I need further information to reproduce it...
Currently I have only a complete log of build process. But if this can help, also I will upload executable and necessary DLLs with embedded debug info.



19.04.2022 21:13, Lukáš Karas wrote:

> With released version, you mean 1.1.0 from 2018? It is pretty old...

Yes, this one. By compiling it I was trying to investigate who is responsible for this problem - compiler/linker or sources.

Re: [Libosmscout-development] Incomplete maps conversion by Import utility

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

Hi. 

I am not aware of any issue that would be causing import issues. I just 
compiled import (today's master) tool on Linux with asserts and address 
sanitizer and it seems to be working properly. So the issue may be platform or 
toolchain specific. Did you tried to enable debug output (with -d argument)? I 
am worry that this issue would require some digging with debugger.

With released version, you mean 1.1.0 from 2018? It is pretty old... But it 
would be possible to use it as starting point for git digest, if you are 
familiar with this technique...

Lukas

Dne úterý 19. dubna 2022 18:37:17 CEST yup napsal(a):
> Hello.
> 
> During a few days I am trying to compile the libosmscout by using
> MSYS2/MinGW 11.2.
> 
> I tried to do this with two library snapshots - from 9.04.2022 and
> 19.04.2022 - with the same result: compilation and building finishes
> without any errors (and with just a few harmless warnings about unused
> parameters of some functions), but created "Import" utility does not work:
> it starts, produces 18 files and finishes immediately after "Step 3".
> 
> There are no any error messages neither from the operating system, nor from
> the utility itself, it just quietly finishes. The last screen output from
> it is: "File 'maps\andorra\coord.dat' completely written" (I use
> andorra.osm.pbf from geofabrik.de because it is the smallest map file, but
> tried other maps too).
> 
> However, when I compile the release version of the library with the same
> toolset, the "Import" utility works perfectly. So what is wrong with
> current versions? Is something broken in them?
> 
> 
> _______________________________________________
> Libosmscout-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libosmscout-development

Re: [Libosmscout-development] Incomplete maps conversion by Import utility

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

Hello :-)

> I tried to do this with two library snapshots - from 9.04.2022 and 19.04.2022 - with the same result:
> compilation and building finishes without any errors (and with just a few harmless warnings about unused parameters of some functions), but created "Import" utility does not work: it starts, produces 18 files and finishes immediately after "Step 3".
> 
> There are no any error messages neither from the operating system, nor from the utility itself, it just quietly finishes.
> The last screen output from it is: "File 'maps\andorra\coord.dat' completely written" (I use andorra.osm.pbf from geofabrik.de because it is the smallest map file, but tried other maps too).
> 
> However, when I compile the release version of the library with the same toolset, the "Import" utility works perfectly. So what is wrong with current versions? Is something broken in them?

I was not able to reproduce this. I have an up to date MSYS/MINGW 
(pacman -Suy), I'M using the current maste rversion of the github 
repository. I use the meson build (meson debug && cd debug && ninja) and 
the current geofabrik version of andorra:

../debug/Import/Import.exe --typefile ../stylesheets/map.ost 
--destinationDirectory andorra andorra.osm.pbf

...
+ Summary...
    Mandatory files:
    File areaarea.idx: 20.7 KiB
    File areanode.idx: 23.6 KiB
    File arearoute.idx: 178 B
    File areas.dat: 443.9 KiB
    File areaway.idx: 14.0 KiB
    File bounding.dat: 14 B
    File coverage.idx: 260 B
    File intersections.dat: 88.0 KiB
    File intersections.idx: 32.0 KiB
    File location.idx: 43.1 KiB
    File nodes.dat: 54.9 KiB
    File ptroutes.dat: 4 B
    File route.dat: 4.9 KiB
    File router.dat: 298.8 KiB
    File router2.dat: 248 B
    File types.dat: 33.8 KiB
    File water.idx: 2.5 KiB
    File ways.dat: 653.6 KiB
    => 1.7 MiB
    Optional files:
    File areasopt.dat: 38.1 KiB
    File waysopt.dat: 57.5 KiB
    => 95.6 KiB
    Import OK!

I have seen the effects you described using the Visual Studio Build. I 
assume in the case of Visual Studio that the vcpkg builds are 
problematic (inconsistent compiler options?).

Do you also use the meson build or possibly cmake?

I need further information to reproduce it...

Background: We currently hav a number of people that use Linux or Mac OS 
based builds. The Windows based build are maintained (keeping builds and 
tests running) but not actively used.

-- 
Gruß...
     Tim

[Libosmscout-development] Incomplete maps conversion by Import utility

[yup <yu...@bi...>]

Hello.

During a few days I am trying to compile the libosmscout by using MSYS2/MinGW 11.2.

I tried to do this with two library snapshots - from 9.04.2022 and 19.04.2022 - with the same result:
compilation and building finishes without any errors (and with just a few harmless warnings about unused parameters of some functions), but created "Import" utility does not work: it starts, produces 18 files and finishes immediately after "Step 3".

There are no any error messages neither from the operating system, nor from the utility itself, it just quietly finishes.
The last screen output from it is: "File 'maps\andorra\coord.dat' completely written" (I use andorra.osm.pbf from geofabrik.de because it is the smallest map file, but tried other maps too).

However, when I compile the release version of the library with the same toolset, the "Import" utility works perfectly. So what is wrong with current versions? Is something broken in them?

Re: [Libosmscout-development] Cluttered ways

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

Hello,

(I missed this one).

> There is no solution for this right now. Way labels and symbols are handled
> separately in layouter. Can you create issue for that please?

Right. It should though in principle possible. However looking at some 
examples I'm not sure if it would be helpful. There are long street 
names, this resulting in only a few arrows. Possibly there are other 
solutions like an (much smaller) arrow below the name?
-- 
Gruß...
    Tim

Re: [Libosmscout-development] Cluttered ways

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

Hi Vlad. 

There is no solution for this right now. Way labels and symbols are handled 
separately in layouter. Can you create issue for that please?

Thanks, Lukas

Dne sobota 29. ledna 2022 13:39:24 CET Vladimir Vyskocil napsal(a):
> Hi !
> 
> I have a question about way rendering especially the oneway ones where as
> you could see in the screenshot the way labels and oneway arrows often
> overlaps. Is there a solution to avoid this issue ? Maybe the way rendering
> code should treat the labels and the images in the same process allowing to
> alternate both along the path ?

[Libosmscout-development] Rendering performance

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

Hello everybody,

in the context of the GDI backend performance I have enhanced the 
PerformanceTest application to measure the absolute and relative 
performance of each Render Step.

Th epull request is pending: 
https://github.com/Framstag/libosmscout/pull/1209

It already builds but I asked Lukas for some review.

Here are some initial results for the cairo, Qt and agg backend (the GDI 
backend is similar in trend)

I choose level 11, since it is the level with some of the most data.

The most most relevant finding:

The single biggest step is the PreprocessData method and thus there is 
the highest potential to optimize (nearly) all renderer. It would be 
wise to further analyse this - and I likely will do. Other findings are 
less surprising. Areas, ways and labels have the highest cost.

There are also very high max values for some steps, this is also 
something to look after.

I have also measured the GDI backend. The GDI is similar in relative 
step performance (the area rendering is *not* obviously much slower).

I also did some changes to the GDI backend, especially using BitBlt 
instead of using GDI methods for this.

Initialization cost though is still measurable high for GDI.

@Valimir: It should be possible and not much effort to add OSX renderer 
to the test, too.

I also would like to move initialization from the DrawMap method to a 
separate method. This would make things simpler and might reduce 
initialisation cost, too.

Another finding: For more accurate tests one should use multiple 
iterations of the rendering steps.

Cairo

Level: 11
Tiles: 1008 (load 1x, drawn 1x)
  Tot. data  : nodes: 21019 way: 251398 areas: 91699
  Avg. data  : nodes: 20 way: 249 areas: 90
  DB         : total: 328.33 min: 0.09 avg: 0.33 max: 34.94
  Map        : total: 709.60 min: 0.01 avg: 0.70 max: 62.20
                #0 0% total: 0.32 min: 0.00 avg: 0.00 max: 0.00
                #1 0% total: 0.07 min: 0.00 avg: 0.00 max: 0.00
                #2 36% total: 258.12 min: 0.00 avg: 0.26 max: 24.88
                #3 0% total: 0.28 min: 0.00 avg: 0.00 max: 0.00
                #4 1% total: 7.40 min: 0.01 avg: 0.01 max: 0.04
                #5 0% total: 0.09 min: 0.00 avg: 0.00 max: 0.00
                #6 0% total: 0.94 min: 0.00 avg: 0.00 max: 0.00
                #7 18% total: 128.35 min: 0.00 avg: 0.13 max: 13.73
                #8 14% total: 98.04 min: 0.00 avg: 0.10 max: 15.16
                #9 1% total: 5.16 min: 0.00 avg: 0.01 max: 0.95
                #10 0% total: 0.11 min: 0.00 avg: 0.00 max: 0.00
                #11 0% total: 1.43 min: 0.00 avg: 0.00 max: 0.14
                #12 0% total: 0.23 min: 0.00 avg: 0.00 max: 0.01
                #13 0% total: 0.21 min: 0.00 avg: 0.00 max: 0.02
                #14 19% total: 131.77 min: 0.00 avg: 0.13 max: 8.95
                #15 0% total: 0.11 min: 0.00 avg: 0.00 max: 0.00
                #16 0% total: 0.09 min: 0.00 avg: 0.00 max: 0.00
                #17 0% total: 0.07 min: 0.00 avg: 0.00 max: 0.00
                #18 11% total: 76.18 min: 0.00 avg: 0.08 max: 6.41
                #19 0% total: 0.07 min: 0.00 avg: 0.00 max: 0.00

Qt

Level: 11
Tiles: 1008 (load 1x, drawn 1x)
  Tot. data  : nodes: 21019 way: 251398 areas: 91699
  Avg. data  : nodes: 20 way: 249 areas: 90
  DB         : total: 349.01 min: 0.09 avg: 0.35 max: 35.15
  Map        : total: 539.54 min: 0.02 avg: 0.54 max: 46.19
                #0 0% total: 1.91 min: 0.00 avg: 0.00 max: 0.05
                #1 0% total: 0.09 min: 0.00 avg: 0.00 max: 0.00
                #2 47% total: 255.41 min: 0.00 avg: 0.25 max: 25.04
                #3 0% total: 0.16 min: 0.00 avg: 0.00 max: 0.00
                #4 2% total: 9.79 min: 0.01 avg: 0.01 max: 0.05
                #5 0% total: 0.15 min: 0.00 avg: 0.00 max: 0.02
                #6 0% total: 1.03 min: 0.00 avg: 0.00 max: 0.01
                #7 16% total: 87.74 min: 0.00 avg: 0.09 max: 8.44
                #8 11% total: 61.35 min: 0.00 avg: 0.06 max: 10.96
                #9 1% total: 5.65 min: 0.00 avg: 0.01 max: 1.06
                #10 0% total: 0.14 min: 0.00 avg: 0.00 max: 0.00
                #11 0% total: 1.32 min: 0.00 avg: 0.00 max: 0.13
                #12 0% total: 0.25 min: 0.00 avg: 0.00 max: 0.02
                #13 0% total: 0.21 min: 0.00 avg: 0.00 max: 0.01
                #14 16% total: 87.37 min: 0.00 avg: 0.09 max: 5.84
                #15 0% total: 0.14 min: 0.00 avg: 0.00 max: 0.00
                #16 0% total: 0.10 min: 0.00 avg: 0.00 max: 0.00
                #17 0% total: 0.09 min: 0.00 avg: 0.00 max: 0.00
                #18 5% total: 25.94 min: 0.00 avg: 0.03 max: 1.79
                #19 0% total: 0.10 min: 0.00 avg: 0.00 max: 0.00

Agg

Level: 11
Tiles: 1008 (load 1x, drawn 1x)
  Tot. data  : nodes: 21019 way: 251398 areas: 91699
  Avg. data  : nodes: 20 way: 249 areas: 90
  DB         : total: 561.94 min: 0.14 avg: 0.56 max: 56.00
  Map        : total: 1011.35 min: 0.16 avg: 1.00 max: 65.56
                #0 6% total: 56.12 min: 0.05 avg: 0.06 max: 0.22
                #1 0% total: 0.22 min: 0.00 avg: 0.00 max: 0.00
                #2 39% total: 391.46 min: 0.00 avg: 0.39 max: 44.51
                #3 0% total: 0.17 min: 0.00 avg: 0.00 max: 0.00
                #4 10% total: 104.58 min: 0.10 avg: 0.10 max: 0.38
                #5 0% total: 0.15 min: 0.00 avg: 0.00 max: 0.00
                #6 0% total: 1.92 min: 0.00 avg: 0.00 max: 0.01
                #7 10% total: 104.76 min: 0.00 avg: 0.10 max: 8.30
                #8 6% total: 57.28 min: 0.00 avg: 0.06 max: 8.76
                #9 1% total: 7.12 min: 0.00 avg: 0.01 max: 1.34
                #10 0% total: 0.24 min: 0.00 avg: 0.00 max: 0.00
                #11 1% total: 6.95 min: 0.00 avg: 0.01 max: 0.54
                #12 0% total: 0.38 min: 0.00 avg: 0.00 max: 0.03
                #13 0% total: 0.28 min: 0.00 avg: 0.00 max: 0.02
                #14 23% total: 234.28 min: 0.00 avg: 0.23 max: 14.42
                #15 0% total: 0.18 min: 0.00 avg: 0.00 max: 0.00
                #16 0% total: 0.12 min: 0.00 avg: 0.00 max: 0.00
                #17 0% total: 0.13 min: 0.00 avg: 0.00 max: 0.00
                #18 3% total: 26.46 min: 0.00 avg: 0.03 max: 1.68
                #19 2% total: 17.52 min: 0.01 avg: 0.02 max: 0.12
-- 
Gruß...
    Tim

[Libosmscout-development] Cluttered ways

[Vladimir V. <vla...@gm...>]

Hi !

I have a question about way rendering especially the oneway ones where as you could see in the screenshot the way labels and oneway arrows often overlaps. Is there a solution to avoid this issue ? Maybe the way rendering code should treat the labels and the images in the same process allowing to alternate both along the path ?

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

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

Hello David,

> My Improvements were applied to DrawAreas and DrawWays (calculating 
> before the main loop the max elements possible for points, so the 
> allocation and re-allocation each time is done just 1 time at the 
> beginning.
> 
> But this needs to move both methods out of MapPainter (as virtual...) So 
> it can be redefined at MapPainterGDI class.
> 
> But with all this done, I met the next step... the ExcludeClip function 
> that takes almost 30milisecs in some of the clipping. (when zoom is in 
> the time can reach to 5 secs to render).

This is exactly what I improved. I reduced the number of allocations and 
reallocations at various places. IT currently does not look like 
clipping is a principle problem.

I'm currently enhancing the PerformanceTest application to be able to 
measure the performance of the renderer in comparison to other renderers.
-- 
Gruß...
    Tim

Re: [Libosmscout-development] Changing the source of position data for the map in QML API

[Asim M. <mah...@gm...>]

Thanks for the reply Lukas!

Yes, upon closer examination, it looks like I only need to call the
locationChanged function to change the position in the map.
The usecase is to use the GPS data from an external source (such as an GPS
sensor) as the source of positional data in the map. So, as long as I get
the data from the sensor and call the locationChanged with the new
position, it should be fine.

Again, thanks for your help!
Regards,
Asim Maharjan

On Tue, Jan 18, 2022 at 2:26 PM Lukáš Karas <luk...@ce...> wrote:

> Hi Asim,
>
> I am not sure if I understand your question. Using the locationChanged
> slot is
> the only way that can be used for setup position to MapWidget. But of
> course,
> nothing prevents you to use different position source than QML
> PositionSource.
>
> There is c++ counterpart for QML PositionSource. It is called
> QGeoPositionInfoSource in c++ api:
> https://doc.qt.io/qt-5/qgeopositioninfosource.html
>
> And in NavigationSimulation demo is used PositionSimulator that reads gpx
> file
> and "replay" location changes from it. You can use any other platform
> specific
> sources of position.
>
> Did I reply your question? What is your exact usecase?
>
> Lukas
>
> Dne úterý 18. ledna 2022 4:59:32 CET Asim Maharjan napsal(a):
> > Greetings everyone,
> > By experimenting with the QT/QML API, I found that the map uses the
> > PositionSource component of Qt for getting the positional data.
> >
> > Is there any other way to provide the position/location data to the Map
> > widget so that it can be displayed using showCurrentPosition?
> >
> > Regards,
> > Asim Maharjan

Re: [Libosmscout-development] Changing the source of position data for the map in QML API

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

Hi Asim, 

I am not sure if I understand your question. Using the locationChanged slot is 
the only way that can be used for setup position to MapWidget. But of course, 
nothing prevents you to use different position source than QML PositionSource.

There is c++ counterpart for QML PositionSource. It is called 
QGeoPositionInfoSource in c++ api: 
https://doc.qt.io/qt-5/qgeopositioninfosource.html

And in NavigationSimulation demo is used PositionSimulator that reads gpx file 
and "replay" location changes from it. You can use any other platform specific 
sources of position.

Did I reply your question? What is your exact usecase?

Lukas

Dne úterý 18. ledna 2022 4:59:32 CET Asim Maharjan napsal(a):
> Greetings everyone,
> By experimenting with the QT/QML API, I found that the map uses the
> PositionSource component of Qt for getting the positional data.
> 
> Is there any other way to provide the position/location data to the Map
> widget so that it can be displayed using showCurrentPosition?
> 
> Regards,
> Asim Maharjan

[Libosmscout-development] Changing the source of position data for the map in QML API

[Asim M. <mah...@gm...>]

Greetings everyone,
By experimenting with the QT/QML API, I found that the map uses the
PositionSource component of Qt for getting the positional data.

Is there any other way to provide the position/location data to the Map
widget so that it can be displayed using showCurrentPosition?

Regards,
Asim Maharjan

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

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

Hello,

My Improvements were applied to DrawAreas and DrawWays (calculating before
the main loop the max elements possible for points, so the allocation and
re-allocation each time is done just 1 time at the beginning.

But this needs to move both methods out of MapPainter (as virtual...) So it
can be redefined at MapPainterGDI class.

But with all this done, I met the next step... the ExcludeClip function
that takes almost 30milisecs in some of the clipping. (when zoom is in the
time can reach to 5 secs to render).



On Sun, 16 Jan 2022 at 09:02, Tim Teulings <ti...@fr...> wrote:

> Hi David,
>
> > pRender->m_pGraphics->ExcludeClip(cr.region);
> >
> > is the bottleneck of drawAreas.
>
> I had some time yesterday. As before the reason was bad programming in
> the sense, that too many (re)allocation were made. I was able to make a
> simple fix, which seemed to have improved rendering time again.
>
> Please update and test. It would be interesting to hear if you see an
> improvement, too, and how big it is.
>
> On my system data loading during zoom in/out already seems to be the
> much slower part. It would be interesting to see, why. I use a debug
> build, that wold have to be checked first.
>
> (AFAIK IO system of Windows is slow, but that slow...?).
> --
> 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 everybody,

I have done some further measurement using the PerformanceTest application:

The call I used:

Demos/PerformanceTest --end-zoom 16 --draw-repeat 0 --load-repeat 2 
../maps/arnsberg-regbez ../stylesheets/standard.oss 1.47038 7.35275 
51.55440 7.57775

Under Windows I used --end-zoom 12 for debug build, else it would have 
been too long (for me ;-)).

Windows and Linux test were made on the same hardware. As one can see, 
Windows Visual Studio debug build is much slower by factors, Windows 
release build is also slower but not by factors.

This is not a test of the drawing backend, but only a test of the IO 
database performance between Linux and Windows for libosmscout (default 
backend is "none").

Of course by integrating the Gdi Backend in the test one could also 
compare backends this way.

For rating of "asynchronous data loading and rendering" see the average 
loading times below...

Linux (debug build):

Level: 0
Tiles: 1 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 4.79176 min: 0.099726 avg: 2.39588 max: 4.69203
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 1
Tiles: 1 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 0.399414 min: 0.077297 avg: 0.199707 max: 0.322117
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 2
Tiles: 1 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 0.408352 min: 0.081037 avg: 0.204176 max: 0.327315
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 3
Tiles: 2 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 0.779403 min: 0.081671 avg: 0.194851 max: 0.407114
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 4
Tiles: 3 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 66 areas: 0
  Avg. data  : nodes: 0 way: 22 areas: 0
  DB         : total: 1.2575 min: 0.071271 avg: 0.209584 max: 0.521686
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 5
Tiles: 6 (load 2x, drawn 0x)
  Tot. data  : nodes: 2 way: 180 areas: 0
  Avg. data  : nodes: 0 way: 30 areas: 0
  DB         : total: 2.62992 min: 0.094361 avg: 0.21916 max: 0.556812
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 6
Tiles: 11 (load 2x, drawn 0x)
  Tot. data  : nodes: 12 way: 341 areas: 42
  Avg. data  : nodes: 1 way: 31 areas: 3
  DB         : total: 4.73479 min: 0.098592 avg: 0.215218 max: 0.568399
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 7
Tiles: 22 (load 2x, drawn 0x)
  Tot. data  : nodes: 39 way: 1963 areas: 300
  Avg. data  : nodes: 1 way: 89 areas: 13
  DB         : total: 14.7137 min: 0.094422 avg: 0.334403 max: 1.40313
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 8
Tiles: 42 (load 2x, drawn 0x)
  Tot. data  : nodes: 33 way: 4335 areas: 1026
  Avg. data  : nodes: 0 way: 103 areas: 24
  DB         : total: 34.4796 min: 0.103902 avg: 0.410472 max: 2.41794
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 9
Tiles: 84 (load 2x, drawn 0x)
  Tot. data  : nodes: 198 way: 10641 areas: 4325
  Avg. data  : nodes: 2 way: 126 areas: 51
  DB         : total: 92.0491 min: 0.112832 avg: 0.547911 max: 9.61837
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 10
Tiles: 336 (load 2x, drawn 0x)
  Tot. data  : nodes: 3317 way: 50212 areas: 32856
  Avg. data  : nodes: 9 way: 149 areas: 97
  DB         : total: 454.339 min: 0.128766 avg: 0.676099 max: 18.3445
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 11
Tiles: 1008 (load 2x, drawn 0x)
  Tot. data  : nodes: 21019 way: 251398 areas: 91699
  Avg. data  : nodes: 20 way: 249 areas: 90
  DB         : total: 396.584 min: 0.022007 avg: 0.196718 max: 34.7816
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 12
Tiles: 2684 (load 2x, drawn 0x)
  Tot. data  : nodes: 14407 way: 867017 areas: 133147
  Avg. data  : nodes: 5 way: 323 areas: 49
  DB         : total: 1592.53 min: 0.02204 avg: 0.296671 max: 72.3348
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 13
Tiles: 8046 (load 2x, drawn 0x)
  Tot. data  : nodes: 10845 way: 901416 areas: 305857
  Avg. data  : nodes: 1 way: 112 areas: 38
  DB         : total: 2600.72 min: 0.022194 avg: 0.161616 max: 27.5807
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 14
Tiles: 29502 (load 2x, drawn 0x)
  Tot. data  : nodes: 22756 way: 1442900 areas: 518861
  Avg. data  : nodes: 0 way: 48 areas: 17
  DB         : total: 7234.8 min: 0.021586 avg: 0.122615 max: 20.0813
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 15
Tiles: 112602 (load 2x, drawn 0x)
  Tot. data  : nodes: 26052 way: 5009813 areas: 5992905
  Avg. data  : nodes: 0 way: 44 areas: 53
  DB         : total: 39017.9 min: 0.021547 avg: 0.173256 max: 44.4787
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0
Level: 16
Tiles: 450366 (load 2x, drawn 0x)
  Tot. data  : nodes: 387970 way: 19247927 areas: 8232262
  Avg. data  : nodes: 0 way: 42 areas: 18
  DB         : total: 187515 min: 0.028026 avg: 0.20818 max: 60.6443
  Map        : total: 0 min: 1.79769e+308 avg: -nan max: 0

Windows, debug build, Defender disabled for the directory (yes, seems to 
make a small difference):

Level: 0
Tiles: 1 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 230.03 min: 3.3871 avg: 115.015 max: 226.643
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 1
Tiles: 1 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 8.7315 min: 3.3571 avg: 4.36575 max: 5.3744
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 2
Tiles: 1 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 12.7915 min: 4.6788 avg: 6.39575 max: 8.1127
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 3
Tiles: 2 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 24.1428 min: 3.5833 avg: 6.0357 max: 9.6682
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 4
Tiles: 3 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 66 areas: 0
  Avg. data  : nodes: 0 way: 22 areas: 0
  DB         : total: 40.1682 min: 3.8826 avg: 6.6947 max: 14.2105
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 5
Tiles: 6 (load 2x, drawn 0x)
  Tot. data  : nodes: 2 way: 180 areas: 0
  Avg. data  : nodes: 0 way: 30 areas: 0
  DB         : total: 98.4595 min: 3.8983 avg: 8.20496 max: 15.5503
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 6
Tiles: 11 (load 2x, drawn 0x)
  Tot. data  : nodes: 12 way: 341 areas: 42
  Avg. data  : nodes: 1 way: 31 areas: 3
  DB         : total: 211.238 min: 3.9524 avg: 9.60172 max: 24.4923
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 7
Tiles: 22 (load 2x, drawn 0x)
  Tot. data  : nodes: 39 way: 1963 areas: 300
  Avg. data  : nodes: 1 way: 89 areas: 13
  DB         : total: 450.697 min: 4.0655 avg: 10.2431 max: 32.3662
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 8
Tiles: 42 (load 2x, drawn 0x)
  Tot. data  : nodes: 33 way: 4335 areas: 1026
  Avg. data  : nodes: 0 way: 103 areas: 24
  DB         : total: 944.466 min: 4.2535 avg: 11.2436 max: 62.4721
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 9
Tiles: 84 (load 2x, drawn 0x)
  Tot. data  : nodes: 198 way: 10641 areas: 4325
  Avg. data  : nodes: 2 way: 126 areas: 51
  DB         : total: 2097.33 min: 4.2851 avg: 12.4841 max: 114.727
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 10
Tiles: 336 (load 2x, drawn 0x)
  Tot. data  : nodes: 3317 way: 50212 areas: 32846
  Avg. data  : nodes: 9 way: 149 areas: 97
  DB         : total: 9815.16 min: 4.3211 avg: 14.6059 max: 253.798
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 11
Tiles: 1008 (load 2x, drawn 0x)
  Tot. data  : nodes: 21019 way: 251347 areas: 91699
  Avg. data  : nodes: 20 way: 249 areas: 90
  DB         : total: 16148.4 min: 3.4787 avg: 8.01014 max: 1101.48
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 12
Tiles: 2684 (load 2x, drawn 0x)
  Tot. data  : nodes: 14404 way: 866918 areas: 133115
  Avg. data  : nodes: 5 way: 322 areas: 49
  DB         : total: 246443 min: 3.5044 avg: 45.9096 max: 37019.3
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0

Windows release build:

Level: 0
Tiles: 1 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 6.4009 min: 0.3098 avg: 3.20045 max: 6.0911
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 1
Tiles: 1 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 0.4293 min: 0.0684 avg: 0.21465 max: 0.3609
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 2
Tiles: 1 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 0.6921 min: 0.0651 avg: 0.34605 max: 0.627
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 3
Tiles: 2 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 0 areas: 0
  Avg. data  : nodes: 0 way: 0 areas: 0
  DB         : total: 1.082 min: 0.06 avg: 0.2705 max: 0.6549
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 4
Tiles: 3 (load 2x, drawn 0x)
  Tot. data  : nodes: 0 way: 66 areas: 0
  Avg. data  : nodes: 0 way: 22 areas: 0
  DB         : total: 1.7865 min: 0.0758 avg: 0.29775 max: 0.8841
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 5
Tiles: 6 (load 2x, drawn 0x)
  Tot. data  : nodes: 2 way: 180 areas: 0
  Avg. data  : nodes: 0 way: 30 areas: 0
  DB         : total: 4.1579 min: 0.081 avg: 0.346492 max: 0.9692
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 6
Tiles: 11 (load 2x, drawn 0x)
  Tot. data  : nodes: 12 way: 341 areas: 42
  Avg. data  : nodes: 1 way: 31 areas: 3
  DB         : total: 10.8679 min: 0.0942 avg: 0.493995 max: 1.7274
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 7
Tiles: 22 (load 2x, drawn 0x)
  Tot. data  : nodes: 39 way: 1963 areas: 300
  Avg. data  : nodes: 1 way: 89 areas: 13
  DB         : total: 27.2305 min: 0.1162 avg: 0.618875 max: 3.6069
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 8
Tiles: 42 (load 2x, drawn 0x)
  Tot. data  : nodes: 33 way: 4335 areas: 1026
  Avg. data  : nodes: 0 way: 103 areas: 24
  DB         : total: 64.6939 min: 0.1219 avg: 0.770165 max: 5.8092
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 9
Tiles: 84 (load 2x, drawn 0x)
  Tot. data  : nodes: 198 way: 10641 areas: 4325
  Avg. data  : nodes: 2 way: 126 areas: 51
  DB         : total: 155.797 min: 0.1368 avg: 0.927361 max: 17.3725
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 10
Tiles: 336 (load 2x, drawn 0x)
  Tot. data  : nodes: 3317 way: 50212 areas: 32846
  Avg. data  : nodes: 9 way: 149 areas: 97
  DB         : total: 723.786 min: 0.1331 avg: 1.07706 max: 30.7029
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 11
Tiles: 1008 (load 2x, drawn 0x)
  Tot. data  : nodes: 21019 way: 251347 areas: 91699
  Avg. data  : nodes: 20 way: 249 areas: 90
  DB         : total: 633.979 min: 0.0638 avg: 0.314474 max: 48.3209
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 12
Tiles: 2684 (load 2x, drawn 0x)
  Tot. data  : nodes: 14404 way: 866918 areas: 133115
  Avg. data  : nodes: 5 way: 322 areas: 49
  DB         : total: 1931.82 min: 0.0648 avg: 0.359877 max: 66.0343
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 13
Tiles: 8046 (load 2x, drawn 0x)
  Tot. data  : nodes: 10845 way: 901281 areas: 305820
  Avg. data  : nodes: 1 way: 112 areas: 38
  DB         : total: 4568.8 min: 0.0782 avg: 0.283917 max: 104.568
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 14
Tiles: 29502 (load 2x, drawn 0x)
  Tot. data  : nodes: 22756 way: 1442738 areas: 518421
  Avg. data  : nodes: 0 way: 48 areas: 17
  DB         : total: 13976 min: 0.0815 avg: 0.236866 max: 17.223
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 15
Tiles: 112602 (load 2x, drawn 0x)
  Tot. data  : nodes: 26052 way: 5008749 areas: 5992559
  Avg. data  : nodes: 0 way: 44 areas: 53
  DB         : total: 60405.5 min: 0.0797 avg: 0.268226 max: 31.1176
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0
Level: 16
Tiles: 450366 (load 2x, drawn 0x)
  Tot. data  : nodes: 387954 way: 19243806 areas: 8231655
  Avg. data  : nodes: 0 way: 42 areas: 18
  DB         : total: 274066 min: 0.0887 avg: 0.30427 max: 79.4635
  Map        : total: 0 min: 1.79769e+308 avg: -nan(ind) max: 0

-- 
Gruß...
     Tim

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

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

Hi David,

> pRender->m_pGraphics->ExcludeClip(cr.region);
> 
> is the bottleneck of drawAreas.

I had some time yesterday. As before the reason was bad programming in 
the sense, that too many (re)allocation were made. I was able to make a 
simple fix, which seemed to have improved rendering time again.

Please update and test. It would be interesting to hear if you see an 
improvement, too, and how big it is.

On my system data loading during zoom in/out already seems to be the 
much slower part. It would be interesting to see, why. I use a debug 
build, that wold have to be checked first.

(AFAIK IO system of Windows is slow, but that slow...?).
-- 
Gruß...
    Tim

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

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

Hello,

pRender->m_pGraphics->ExcludeClip(cr.region);

is the bottleneck of drawAreas.

I think to make a good gdi render + movement application the view should be
divided in small tiles and prefetching the boundaries while the main bitmap
is showed so each movement could be prebufered and speed would be great.
But this needs time that I don't have.





On Tue, 11 Jan 2022 at 11:01, David Huelves Ramos <dav...@gm...>
wrote:

> Hello,
>
> After some improvements:
>
> DrawAreas (Clipping) is still getting too much time to render. At this
> point I can't improve more as I don't know how clipping works.
>
> Regards
>
>
>
>
> On Mon, 10 Jan 2022 at 08:47, David Huelves Ramos <dav...@gm...>
> wrote:
>
>> BTW.
>>
>> Adding:
>>
>>   case WM_ERASEBKGND:
>>             return TRUE;
>>
>> To:
>>
>> LRESULT MapPainterGDIWindow::WinMsgHandler(HWND hwnd, UINT uMsg, WPARAM
>> wParam, LPARAM lParam)
>>
>>
>> Flickering is avoided.
>>
>>
>>
>>
>> On Mon, 10 Jan 2022 at 08:43, David Huelves Ramos <
>> dav...@gm...> wrote:
>>
>>> Sorry,
>>>
>>> Don't understand the Invalidate(TRUE) statement.... as Invalidate is
>>> already called with TRUE as parameter.
>>>
>>> [image: image.png]
>>>
>>>
>>>
>>> On Mon, 10 Jan 2022 at 07:39, Tim Teulings <ti...@fr...> wrote:
>>>
>>>> Hello David,
>>>>
>>>> > Thanks for your work.
>>>> >
>>>> > I'll check it out this week.
>>>> >
>>>> > What Should I do to get the modifications?
>>>> My pull request has already been merged to master.
>>>>
>>>> You could see pending pull requests here:
>>>> https://github.com/Framstag/libosmscout/pulls
>>>>
>>>> You can see past pull requests here (just dropping the is:open filter):
>>>> https://github.com/Framstag/libosmscout/pulls?q=is%3Apr
>>>>
>>>> You can also see the diffs behind the pull requests also by following
>>>> the links there.
>>>>
>>>> --
>>>> 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,

After some improvements:

DrawAreas (Clipping) is still getting too much time to render. At this
point I can't improve more as I don't know how clipping works.

Regards




On Mon, 10 Jan 2022 at 08:47, David Huelves Ramos <dav...@gm...>
wrote:

> BTW.
>
> Adding:
>
>   case WM_ERASEBKGND:
>             return TRUE;
>
> To:
>
> LRESULT MapPainterGDIWindow::WinMsgHandler(HWND hwnd, UINT uMsg, WPARAM
> wParam, LPARAM lParam)
>
>
> Flickering is avoided.
>
>
>
>
> On Mon, 10 Jan 2022 at 08:43, David Huelves Ramos <dav...@gm...>
> wrote:
>
>> Sorry,
>>
>> Don't understand the Invalidate(TRUE) statement.... as Invalidate is
>> already called with TRUE as parameter.
>>
>> [image: image.png]
>>
>>
>>
>> On Mon, 10 Jan 2022 at 07:39, Tim Teulings <ti...@fr...> wrote:
>>
>>> Hello David,
>>>
>>> > Thanks for your work.
>>> >
>>> > I'll check it out this week.
>>> >
>>> > What Should I do to get the modifications?
>>> My pull request has already been merged to master.
>>>
>>> You could see pending pull requests here:
>>> https://github.com/Framstag/libosmscout/pulls
>>>
>>> You can see past pull requests here (just dropping the is:open filter):
>>> https://github.com/Framstag/libosmscout/pulls?q=is%3Apr
>>>
>>> You can also see the diffs behind the pull requests also by following
>>> the links there.
>>>
>>> --
>>> 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...>]

BTW.

Adding:

  case WM_ERASEBKGND:
            return TRUE;

To:

LRESULT MapPainterGDIWindow::WinMsgHandler(HWND hwnd, UINT uMsg, WPARAM
wParam, LPARAM lParam)


Flickering is avoided.




On Mon, 10 Jan 2022 at 08:43, David Huelves Ramos <dav...@gm...>
wrote:

> Sorry,
>
> Don't understand the Invalidate(TRUE) statement.... as Invalidate is
> already called with TRUE as parameter.
>
> [image: image.png]
>
>
>
> On Mon, 10 Jan 2022 at 07:39, Tim Teulings <ti...@fr...> wrote:
>
>> Hello David,
>>
>> > Thanks for your work.
>> >
>> > I'll check it out this week.
>> >
>> > What Should I do to get the modifications?
>> My pull request has already been merged to master.
>>
>> You could see pending pull requests here:
>> https://github.com/Framstag/libosmscout/pulls
>>
>> You can see past pull requests here (just dropping the is:open filter):
>> https://github.com/Framstag/libosmscout/pulls?q=is%3Apr
>>
>> You can also see the diffs behind the pull requests also by following
>> the links there.
>>
>> --
>> 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...>]

Sorry,

Don't understand the Invalidate(TRUE) statement.... as Invalidate is
already called with TRUE as parameter.

[image: image.png]



On Mon, 10 Jan 2022 at 07:39, Tim Teulings <ti...@fr...> wrote:

> Hello David,
>
> > Thanks for your work.
> >
> > I'll check it out this week.
> >
> > What Should I do to get the modifications?
> My pull request has already been merged to master.
>
> You could see pending pull requests here:
> https://github.com/Framstag/libosmscout/pulls
>
> You can see past pull requests here (just dropping the is:open filter):
> https://github.com/Framstag/libosmscout/pulls?q=is%3Apr
>
> You can also see the diffs behind the pull requests also by following
> the links there.
>
> --
> 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,

> Thanks for your work.
> 
> I'll check it out this week.
> 
> What Should I do to get the modifications?
My pull request has already been merged to master.

You could see pending pull requests here: 
https://github.com/Framstag/libosmscout/pulls

You can see past pull requests here (just dropping the is:open filter): 
https://github.com/Framstag/libosmscout/pulls?q=is%3Apr

You can also see the diffs behind the pull requests also by following 
the links there.

-- 
Gruß...
    Tim

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

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

Hello Tim,

Thanks for your work.

I'll check it out this week.

What Should I do to get the modifications?

On Sat, 8 Jan 2022 at 17:06, Tim <ti...@fr...> wrote:

> Hello David,
>
> It looks like this is possibly caused by Windows Event handling
> mechnismn, clipping regions and order of things changed.
>
> I currently seem to have fixed it by just passing erase=TRUE to
> InvalidateRect. But things should work with erase=false if everything
> else works as expected.
>
> I created a new pull request, which adds some logging, fixes some Clion
> warnings and does smaller changes to the code. This is not a general fix
> but the additional logs should be helpful.
>
> I also now have a better setup under Windows (Clion working with cmake
> and Visual Studio), so future changes should be simpler for me.
>
> Rendering is still slow, but now it seems to be data loading is slowing
> things down. The zooming code also seems to be not optimal, but I use
> zooming via touch pad, possibly this creates strange WHEEL messages.
>
> The Demo application is also sometimes showing a sand glass, also a hint
> of a busy/slow event loop.
>
> I'll see if I add control + and control -.
>
> Sorry for the late response work, family and a cold took their share
> this week...
>
> --
> 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,

It looks like this is possibly caused by Windows Event handling 
mechnismn, clipping regions and order of things changed.

I currently seem to have fixed it by just passing erase=TRUE to 
InvalidateRect. But things should work with erase=false if everything 
else works as expected.

I created a new pull request, which adds some logging, fixes some Clion 
warnings and does smaller changes to the code. This is not a general fix 
but the additional logs should be helpful.

I also now have a better setup under Windows (Clion working with cmake 
and Visual Studio), so future changes should be simpler for me.

Rendering is still slow, but now it seems to be data loading is slowing 
things down. The zooming code also seems to be not optimal, but I use 
zooming via touch pad, possibly this creates strange WHEEL messages.

The Demo application is also sometimes showing a sand glass, also a hint 
of a busy/slow event loop.

I'll see if I add control + and control -.

Sorry for the late response work, family and a cold took their share 
this week...

-- 
Gruß...
     Tim

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

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

Well the problem is in the osmscout as It cleans with the "new" coordinates
when it should be done with the old ones.
I'm trying to correct it but Maybe Tim you can do it faster than me :S

On Tue, 4 Jan 2022 at 10:29, David Huelves Ramos <dav...@gm...>
wrote:

> 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
>
>