libosmscout-development — Talk about the development of libosmscout

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

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

Hello David,

> Could you please share the changes you did here?.

See here:

>     Changes will be committed as soon as the pull requests builds pass:
> 
>     https://github.com/Framstag/libosmscout/pull/1189
>     <https://github.com/Framstag/libosmscout/pull/1189>

Simple changes. The most important one possibly the clearing of the 
MapData in OnTileUpdate().

Changes will be in master once the build passes (soon ;-))

-- 
Gruß...
     Tim

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

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

Hi,

Thanks to all.

I didn't have time to check the DrawMapGDI library to check what's going on
there.

I'll check tomorrow.

Could you please share the changes you did here?.

Regards


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

> Hello everybody,
>
> I now made a simple test using DrawMapCairo nd DrawMapGDI. Before I
> fixed the "multiple aceesses to the pen map" issue in the GDI driver.
>
> Here are the rendering times:
>
> DrawMapGDI:
>
> Prep: 0.138 (sec) 0.140 (sec) 0.004 (sec)
> Draw: [51.50566 N 7.44596 E - 51.51916 N 7.48454 E] 70000x/16 1920x1080
> 96.00000 DPI
> Draw areas: 6099 (pcs) 0.117 (s)
> Draw ways: 4275 (pcs) 0.084 (s)
> Draw way decorations: 467 (pcs) 0.012(s)
> Draw way contour labels: 801 (pcs) 0.119(s)
> Draw area labels: 6099 (pcs) 0.145(s)
> Draw area border labels: 0 (pcs) 0.002(s)
> Draw area border symbols: 0 (pcs) 0.001(s)
> Prepare node labels: 0.074(s)
>
> DrawMapCairo:
>
> Prep: 0.143 (sec) 0.138 (sec) 0.004 (sec)
> Draw: [51.50566 N 7.44596 E - 51.51916 N 7.48454 E] 70000x/16 1920x1080
> 96.00000 DPI
> ERROR while loading pattern image 'scrub'
> Draw areas: 6099 (pcs) 0.396 (s)
> Draw ways: 4275 (pcs) 0.278 (s)
> Draw way decorations: 467 (pcs) 0.024(s)
> Draw way contour labels: 801 (pcs) 0.130(s)
> Draw area labels: 6099 (pcs) 0.349(s)
> Draw area border labels: 0 (pcs) 0.003(s)
> Draw area border symbols: 0 (pcs) 0.002(s)
> Prepare node labels: 0.191(s)
>
> I also found a bug in the DrwMapGDI demo, where the MapData structure
> was not cleared and rerendering. In the original measurement this could
> be seen by all "pcs" values doubled for thr GDI version.
>
> The GDI demo still feels slow and sluggish, but this is not because of
> the rendering. Above is not a good performance tests, but rendeirng
> times do not seem to be slow (even possibly better than for the Cairo
> backend).
>
> Changes will be committed as soon as the pull requests builds pass:
>
> https://github.com/Framstag/libosmscout/pull/1189
>
> --
> 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 now made a simple test using DrawMapCairo nd DrawMapGDI. Before I 
fixed the "multiple aceesses to the pen map" issue in the GDI driver.

Here are the rendering times:

DrawMapGDI:

Prep: 0.138 (sec) 0.140 (sec) 0.004 (sec)
Draw: [51.50566 N 7.44596 E - 51.51916 N 7.48454 E] 70000x/16 1920x1080 
96.00000 DPI
Draw areas: 6099 (pcs) 0.117 (s)
Draw ways: 4275 (pcs) 0.084 (s)
Draw way decorations: 467 (pcs) 0.012(s)
Draw way contour labels: 801 (pcs) 0.119(s)
Draw area labels: 6099 (pcs) 0.145(s)
Draw area border labels: 0 (pcs) 0.002(s)
Draw area border symbols: 0 (pcs) 0.001(s)
Prepare node labels: 0.074(s)

DrawMapCairo:

Prep: 0.143 (sec) 0.138 (sec) 0.004 (sec)
Draw: [51.50566 N 7.44596 E - 51.51916 N 7.48454 E] 70000x/16 1920x1080 
96.00000 DPI
ERROR while loading pattern image 'scrub'
Draw areas: 6099 (pcs) 0.396 (s)
Draw ways: 4275 (pcs) 0.278 (s)
Draw way decorations: 467 (pcs) 0.024(s)
Draw way contour labels: 801 (pcs) 0.130(s)
Draw area labels: 6099 (pcs) 0.349(s)
Draw area border labels: 0 (pcs) 0.003(s)
Draw area border symbols: 0 (pcs) 0.002(s)
Prepare node labels: 0.191(s)

I also found a bug in the DrwMapGDI demo, where the MapData structure 
was not cleared and rerendering. In the original measurement this could 
be seen by all "pcs" values doubled for thr GDI version.

The GDI demo still feels slow and sluggish, but this is not because of 
the rendering. Above is not a good performance tests, but rendeirng 
times do not seem to be slow (even possibly better than for the Cairo 
backend).

Changes will be committed as soon as the pull requests builds pass:

https://github.com/Framstag/libosmscout/pull/1189

-- 
Gruß...
     Tim

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

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

Hello,

I have looked at MapPainterGDI::DrawPath and the methods used there.

The DrawPath implementation looks straight forward. But the GetPen 
method is expensive on creation of pens, since it accesses the m_Pens 
map multiple times. This should be easy to fix.

Also the operator< method of PENDEF looks rather expensive.

It looks like it would be wise to measure if caching of pens makes this 
backend faster or slower. We do not cache such structures in other 
backends (besides fonts AFAIK).

The best strategically way would possibly to expend the PerformanceTest 
demo to also make use of the GDI backend. This would allow to compare 
the different backends directly.
-- 
Gruß...
    Tim

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

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

Hello David,

this are the rendering timings using the OSMScout2 demo application (qt 
backend under Linux, Wayland) for zooming in on my hometown (~600.000 
people)

Data: 356+0 36308 4894
Type : highway_tertiary has 2359 objects (performance limit: 1000)
Type : highway_primary has 1993 objects (performance limit: 1000)
Type : landuse_farmland has 1113 objects (performance limit: 1000)
Type : landuse_farmland has 34166 coords (performance limit: 20000)
Type : highway_motorway_link has 1013 objects (performance limit: 1000)
Type : highway_residential has 15502 objects (performance limit: 1000)
Type : highway_residential has 114304 coords (performance limit: 20000)
Type : waterway_stream has 3293 objects (performance limit: 1000)
Type : waterway_stream has 36467 coords (performance limit: 20000)
Type : highway_unclassified has 2292 objects (performance limit: 1000)
Type : landuse_residential has 46760 coords (performance limit: 20000)
Type : wood has 67674 coords (performance limit: 20000)
Type : natural_scrub has 23542 coords (performance limit: 20000)
Type : highway_secondary has 4582 objects (performance limit: 1000)
Type : highway_secondary has 24526 coords (performance limit: 20000)
Type : railway_rail has 2963 objects (performance limit: 1000)
Type : railway_rail has 22654 coords (performance limit: 20000)
Prep: 0.059 (sec) 0.010 (sec) 0.008 (sec)
Draw: [51,44211 N 7,25166 E - 51,58594 N 7,68306 E] 6302x/12 2880x1543 
143,00000 DPI
Draw areas: 3570 (pcs) 0.112 (s)
Draw ways: 23111 (pcs) 0.253 (s)
Draw way decorations: 0 (pcs) 0.009(s)
Draw way contour labels: 0 (pcs) 0.002(s)
Prepare node labels: 0.002(s)

As you can see:
* Less areas
* More ways
* Ways render much faster

I thus assume that there might be a possibly slow implementation of way 
rendering in the GDI backend? It would be interesting to see what parts 
of the way rendering took that much time.

*How good is your GDI knowledge?*

Regarding rendering in parallel:
Normally the higher the abstraction of the rendering API, the less 
likely you can use multiple threads for APIs calls on the same 
image/bitmap/surface...

There are some parts in the MapPainter implementation that do things 
that might could be parallelized (like sorting things), but it does not 
look like these are driving the performance.

Note also that the number of physical cores is normally limited to 
maximum 4 or 8, so too much parallelism might not help. And remeber that 
we needs some threads for dataloading in parallel (=> double buffer).

With the parallel sorting support in recent C++ standards it should be 
easy to make some tests, to see if it help at all...
-- 
Gruß...
    Tim

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

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

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

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

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

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


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

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

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

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
>

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

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

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

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

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

As far as I now know,

The slowest procedures are DrawWays and DrawAreas. I can't understand
though why logger is not working if I use the default ConsoleLogger
Implementation:

[image: image.png]
The program enters the log areas for writing speeds/timings but nothing is
written.

[image: image.png]


Any Ideas?

On Wed, 29 Dec 2021 at 12:56, David Huelves Ramos <dav...@gm...>
wrote:

> 1 hour later and a few google readings....  (I can debug dll code). I
> continue investigating.
>
>
> [image: image.png]
>
> On Wed, 29 Dec 2021 at 11:51, David Huelves Ramos <dav...@gm...>
> wrote:
>
>> Hello,
>>
>> I'm fighting to include debug capabilities on called dll's to debug them,
>> without luck for now (No symbols loaded on the main 3 dll libraries (_...
>> don`t know why, even if I generate pdb files...).
>>
>> [image: image.png]
>>
>> I'd like to activate the log but I tried (starting it in the main code)
>> and nothing gets out....
>>
>> Next thing would be profiler.
>>
>> Still struggling with it all together.
>>
>>
>>
>>
>>
>> On Tue, 28 Dec 2021 at 13:53, Tim Teulings <ti...@fr...> wrote:
>>
>>> Hello David,
>>>
>>> I try to answer based on (parts of) the DrawMapXXX code:
>>>
>>>    drawDemo.LoadData();
>>>
>>>    if (mapPainter.DrawMap(drawDemo.projection,
>>>                           drawDemo.drawParameter,
>>>                           drawDemo.data,
>>>                           painter)) {
>>>      if (!pixmap->save(QString::fromStdString(args.output),"PNG",-1)) {
>>>        std::cerr << "Cannot write PNG" << std::endl;
>>>      }
>>>    }
>>>
>>>
>>> with LoadData():
>>> ...
>>>      mapService->LookupTiles(projection,tiles);
>>>      mapService->LoadMissingTileData(searchParameter,*styleConfig,tiles);
>>>      mapService->AddTileDataToMapData(tiles,data);
>>> ...
>>>
>>> Libosmscout tries to be modular, separating parts of the pipeline by
>>> different classes, allowing to exchange parts of the pipeline (for
>>> example loading data remote instead form a local database but still use
>>> the renderer).
>>>
>>>
>>> Access to the database is represented by the Database class. It caches
>>> state of the individual database files. Files can get closed to handle
>>> low memory situations, but opening/closing files costs time. As such
>>> database object should be long lived. For every file there is a special
>>> Data or Index class for loading data.
>>>
>>> MapService handles selective loading of data for rendering maps via the
>>> Database object. It is stateful, caching an amount of data tiles. As
>>> such it should have similar lifecycle as the Database.
>>>
>>> mapService->LookupTiles() => Based on the passed projection calculate
>>> the data tiles to be loaded => Expected to be fast.
>>>
>>> mapService->LoadMissingTileData() => Based on the given list of data
>>> tiles and stylesheet missing data is loaded from the database (only data
>>> for the given tiles and only objects of type referenced in the style
>>> sheet for the given magnification). The loading can be done
>>> asynchronously (or you do it in a background thread and call it from
>>> there synchronously). => Fast if data is cached, else slow
>>>
>>> mapService->AddTileDataToMapData() => Interface between the database and
>>> the renderer is the MapData class, containing just a list of data to be
>>> injected into the renderer. => Should be rather fast for reasonable
>>> amounts of data.
>>>
>>> MapData itself is just a transfer object and can get thrown away after
>>> data has been passed. In fact you should not append data but clear it on
>>> use. We recently had somebody ho appended new data, resulting in more
>>> and more data to be rendered on every call.
>>>
>>> mapPainter.DrawMap() => Draw the map based on the passed data.
>>> MapPainter itself is stateless but initialization might be expensive. It
>>> also tries to reuse memory on each call. So you should keep the painter
>>> long lived, too. => Rather fast depending on the amount of data passed.
>>>
>>> Most of the methods also count their running time and drop a log.warn()
>>> if it takes too long.
>>>
>>> I would measure the calls to the MapService and the calls to the
>>> Renderer. The relevant calls should be part of your code. You can use
>>> classes like StopClock and and the Logging framework for this, too.
>>>
>>> --
>>> 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...>]

1 hour later and a few google readings....  (I can debug dll code). I
continue investigating.


[image: image.png]

On Wed, 29 Dec 2021 at 11:51, David Huelves Ramos <dav...@gm...>
wrote:

> Hello,
>
> I'm fighting to include debug capabilities on called dll's to debug them,
> without luck for now (No symbols loaded on the main 3 dll libraries (_...
> don`t know why, even if I generate pdb files...).
>
> [image: image.png]
>
> I'd like to activate the log but I tried (starting it in the main code)
> and nothing gets out....
>
> Next thing would be profiler.
>
> Still struggling with it all together.
>
>
>
>
>
> On Tue, 28 Dec 2021 at 13:53, Tim Teulings <ti...@fr...> wrote:
>
>> Hello David,
>>
>> I try to answer based on (parts of) the DrawMapXXX code:
>>
>>    drawDemo.LoadData();
>>
>>    if (mapPainter.DrawMap(drawDemo.projection,
>>                           drawDemo.drawParameter,
>>                           drawDemo.data,
>>                           painter)) {
>>      if (!pixmap->save(QString::fromStdString(args.output),"PNG",-1)) {
>>        std::cerr << "Cannot write PNG" << std::endl;
>>      }
>>    }
>>
>>
>> with LoadData():
>> ...
>>      mapService->LookupTiles(projection,tiles);
>>      mapService->LoadMissingTileData(searchParameter,*styleConfig,tiles);
>>      mapService->AddTileDataToMapData(tiles,data);
>> ...
>>
>> Libosmscout tries to be modular, separating parts of the pipeline by
>> different classes, allowing to exchange parts of the pipeline (for
>> example loading data remote instead form a local database but still use
>> the renderer).
>>
>>
>> Access to the database is represented by the Database class. It caches
>> state of the individual database files. Files can get closed to handle
>> low memory situations, but opening/closing files costs time. As such
>> database object should be long lived. For every file there is a special
>> Data or Index class for loading data.
>>
>> MapService handles selective loading of data for rendering maps via the
>> Database object. It is stateful, caching an amount of data tiles. As
>> such it should have similar lifecycle as the Database.
>>
>> mapService->LookupTiles() => Based on the passed projection calculate
>> the data tiles to be loaded => Expected to be fast.
>>
>> mapService->LoadMissingTileData() => Based on the given list of data
>> tiles and stylesheet missing data is loaded from the database (only data
>> for the given tiles and only objects of type referenced in the style
>> sheet for the given magnification). The loading can be done
>> asynchronously (or you do it in a background thread and call it from
>> there synchronously). => Fast if data is cached, else slow
>>
>> mapService->AddTileDataToMapData() => Interface between the database and
>> the renderer is the MapData class, containing just a list of data to be
>> injected into the renderer. => Should be rather fast for reasonable
>> amounts of data.
>>
>> MapData itself is just a transfer object and can get thrown away after
>> data has been passed. In fact you should not append data but clear it on
>> use. We recently had somebody ho appended new data, resulting in more
>> and more data to be rendered on every call.
>>
>> mapPainter.DrawMap() => Draw the map based on the passed data.
>> MapPainter itself is stateless but initialization might be expensive. It
>> also tries to reuse memory on each call. So you should keep the painter
>> long lived, too. => Rather fast depending on the amount of data passed.
>>
>> Most of the methods also count their running time and drop a log.warn()
>> if it takes too long.
>>
>> I would measure the calls to the MapService and the calls to the
>> Renderer. The relevant calls should be part of your code. You can use
>> classes like StopClock and and the Logging framework for this, too.
>>
>> --
>> 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'm fighting to include debug capabilities on called dll's to debug them,
without luck for now (No symbols loaded on the main 3 dll libraries (_...
don`t know why, even if I generate pdb files...).

[image: image.png]

I'd like to activate the log but I tried (starting it in the main code) and
nothing gets out....

Next thing would be profiler.

Still struggling with it all together.





On Tue, 28 Dec 2021 at 13:53, Tim Teulings <ti...@fr...> wrote:

> Hello David,
>
> I try to answer based on (parts of) the DrawMapXXX code:
>
>    drawDemo.LoadData();
>
>    if (mapPainter.DrawMap(drawDemo.projection,
>                           drawDemo.drawParameter,
>                           drawDemo.data,
>                           painter)) {
>      if (!pixmap->save(QString::fromStdString(args.output),"PNG",-1)) {
>        std::cerr << "Cannot write PNG" << std::endl;
>      }
>    }
>
>
> with LoadData():
> ...
>      mapService->LookupTiles(projection,tiles);
>      mapService->LoadMissingTileData(searchParameter,*styleConfig,tiles);
>      mapService->AddTileDataToMapData(tiles,data);
> ...
>
> Libosmscout tries to be modular, separating parts of the pipeline by
> different classes, allowing to exchange parts of the pipeline (for
> example loading data remote instead form a local database but still use
> the renderer).
>
>
> Access to the database is represented by the Database class. It caches
> state of the individual database files. Files can get closed to handle
> low memory situations, but opening/closing files costs time. As such
> database object should be long lived. For every file there is a special
> Data or Index class for loading data.
>
> MapService handles selective loading of data for rendering maps via the
> Database object. It is stateful, caching an amount of data tiles. As
> such it should have similar lifecycle as the Database.
>
> mapService->LookupTiles() => Based on the passed projection calculate
> the data tiles to be loaded => Expected to be fast.
>
> mapService->LoadMissingTileData() => Based on the given list of data
> tiles and stylesheet missing data is loaded from the database (only data
> for the given tiles and only objects of type referenced in the style
> sheet for the given magnification). The loading can be done
> asynchronously (or you do it in a background thread and call it from
> there synchronously). => Fast if data is cached, else slow
>
> mapService->AddTileDataToMapData() => Interface between the database and
> the renderer is the MapData class, containing just a list of data to be
> injected into the renderer. => Should be rather fast for reasonable
> amounts of data.
>
> MapData itself is just a transfer object and can get thrown away after
> data has been passed. In fact you should not append data but clear it on
> use. We recently had somebody ho appended new data, resulting in more
> and more data to be rendered on every call.
>
> mapPainter.DrawMap() => Draw the map based on the passed data.
> MapPainter itself is stateless but initialization might be expensive. It
> also tries to reuse memory on each call. So you should keep the painter
> long lived, too. => Rather fast depending on the amount of data passed.
>
> Most of the methods also count their running time and drop a log.warn()
> if it takes too long.
>
> I would measure the calls to the MapService and the calls to the
> Renderer. The relevant calls should be part of your code. You can use
> classes like StopClock and and the Logging framework for this, too.
>
> --
> 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 try to answer based on (parts of) the DrawMapXXX code:

   drawDemo.LoadData();

   if (mapPainter.DrawMap(drawDemo.projection,
                          drawDemo.drawParameter,
                          drawDemo.data,
                          painter)) {
     if (!pixmap->save(QString::fromStdString(args.output),"PNG",-1)) {
       std::cerr << "Cannot write PNG" << std::endl;
     }
   }


with LoadData():
...
     mapService->LookupTiles(projection,tiles);
     mapService->LoadMissingTileData(searchParameter,*styleConfig,tiles);
     mapService->AddTileDataToMapData(tiles,data);
...

Libosmscout tries to be modular, separating parts of the pipeline by 
different classes, allowing to exchange parts of the pipeline (for 
example loading data remote instead form a local database but still use 
the renderer).


Access to the database is represented by the Database class. It caches 
state of the individual database files. Files can get closed to handle 
low memory situations, but opening/closing files costs time. As such 
database object should be long lived. For every file there is a special 
Data or Index class for loading data.

MapService handles selective loading of data for rendering maps via the 
Database object. It is stateful, caching an amount of data tiles. As 
such it should have similar lifecycle as the Database.

mapService->LookupTiles() => Based on the passed projection calculate 
the data tiles to be loaded => Expected to be fast.

mapService->LoadMissingTileData() => Based on the given list of data 
tiles and stylesheet missing data is loaded from the database (only data 
for the given tiles and only objects of type referenced in the style 
sheet for the given magnification). The loading can be done 
asynchronously (or you do it in a background thread and call it from 
there synchronously). => Fast if data is cached, else slow

mapService->AddTileDataToMapData() => Interface between the database and 
the renderer is the MapData class, containing just a list of data to be 
injected into the renderer. => Should be rather fast for reasonable 
amounts of data.

MapData itself is just a transfer object and can get thrown away after 
data has been passed. In fact you should not append data but clear it on 
use. We recently had somebody ho appended new data, resulting in more 
and more data to be rendered on every call.

mapPainter.DrawMap() => Draw the map based on the passed data. 
MapPainter itself is stateless but initialization might be expensive. It 
also tries to reuse memory on each call. So you should keep the painter 
long lived, too. => Rather fast depending on the amount of data passed.

Most of the methods also count their running time and drop a log.warn() 
if it takes too long.

I would measure the calls to the MapService and the calls to the 
Renderer. The relevant calls should be part of your code. You can use 
classes like StopClock and and the Logging framework for this, too.

-- 
Gruß...
    Tim

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

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

Well I deduced:

OnTileUpdate() override prepares the data in the MapServiceRef and the Draw
Engine checks all data on this MapServiceRef to create a bitmap so it can
be drawn.

Then the bottleneck is in the check of this bitmap creation from data. But
I can't debug it neither check how fast is doing things.... (I get lost in
the amount of methods / functions available in each class)




On Tue, 28 Dec 2021 at 12:06, David Huelves Ramos <dav...@gm...>
wrote:

> I tried this way:
>
> [image: image.png]
>
>
> But nothing happened....
>
> BTW, the OnTileUpdate override function is fast, but the render isn't....
>
> How is the pipeline working?
>
> Regards
>
>
> On Mon, 27 Dec 2021 at 18:16, Tim Teulings <ti...@fr...> wrote:
>
>> Hi David,
>>
>> libosmscout libraries do not directly output to the terminal (std::cout
>> << ...) but uses its own (simple) logging framework for this (no
>> security problems here ;-))
>>
>> See Logger.h
>>
>> By Default a ConsoleLogger is assigned but you can exchange it with your
>> own implementation (by for example deriving from StreamLogger and
>> redirecting logs to a file).
>>
>> You should also explicitely turn on the log levels using "SetDebug(true)
>> etc...)
>> --
>> 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 tried this way:

[image: image.png]


But nothing happened....

BTW, the OnTileUpdate override function is fast, but the render isn't....

How is the pipeline working?

Regards


On Mon, 27 Dec 2021 at 18:16, Tim Teulings <ti...@fr...> wrote:

> Hi David,
>
> libosmscout libraries do not directly output to the terminal (std::cout
> << ...) but uses its own (simple) logging framework for this (no
> security problems here ;-))
>
> See Logger.h
>
> By Default a ConsoleLogger is assigned but you can exchange it with your
> own implementation (by for example deriving from StreamLogger and
> redirecting logs to a file).
>
> You should also explicitely turn on the log levels using "SetDebug(true)
> etc...)
> --
> 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...>]

Hi David,

libosmscout libraries do not directly output to the terminal (std::cout 
<< ...) but uses its own (simple) logging framework for this (no 
security problems here ;-))

See Logger.h

By Default a ConsoleLogger is assigned but you can exchange it with your 
own implementation (by for example deriving from StreamLogger and 
redirecting logs to a file).

You should also explicitely turn on the log levels using "SetDebug(true) 
etc...)
-- 
Gruß...
    Tim

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

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

Hi

I added the following lines but no output is written...

[image: image.png]

On Mon, 27 Dec 2021 at 16:19, David Huelves Ramos <dav...@gm...>
wrote:

> Hi,
>
> I thought it was already done (doble buffer).... I'll turn debug variables
> on to check what's going on.
>
> Thanks for your answers.
>
> I'll write back as soon as I get results or problems :-D
>
>
>
> On Mon, 27 Dec 2021 at 15:04, Tim Teulings <ti...@fr...> wrote:
>
>> Hello,
>>
>> > You can get inspiration in "client-qt" library. There are two kind of
>> > renderer:
>> >
>> >   - tiled renderer - background thread is rendering map to tiles,
>> similar as
>> > online raster services, and they are composed to final map in UI thread.
>>
>> This allows to cache tiles and rendering of smaller than screen tiles
>> (which is faster than rendering full screen). On the other hand
>> composing the tiles sometimes results in local glitches.
>>
>> >
>> https://github.com/Framstag/libosmscout/blob/master/libosmscout-client-qt/
>> > include/osmscoutclientqt/TiledMapRenderer.h
>> >
>> >   - plane renderer - there are two map canvases. one owned by UI thread,
>> > it is transformed (zoomed, moved) to expected coordinates and second
>> canvas
>> > that is used for rendering by background thread with updated
>> projection. When
>> > rendering is finished, these canvases are swapped.
>>
>> This would be a classic gaming double buffer technique. Or thing of a
>> asynchronous rendering pipe where the UI sends commands to a background
>> thread ands visualizes the results retrieved later on.
>>
>> Nevertheless, even if you did not implement it this way, rendering time
>> should be correlated to the area moved. And small movements should not
>> take multiple seconds.
>>
>> >
>> https://github.com/Framstag/libosmscout/blob/master/libosmscout-client-qt/
>> > include/osmscoutclientqt/PlaneMapRenderer.h
>> >
>> > We don't have such interactive renderer for GDI unfortunately.
>>
>> Which means, that there is only a client-qt library, but no "client" or
>> "client-windows" library. It would likely possible to move parts of the
>> client-qt library into a client library (to increase reuse) however the
>> Qt library and especially signal-slot mechanism a relative invasive ;-)
>>
>> It would be interesting to see the content of your OnTileUpdate()
>> method. I still assume that there is possible potential for optimization.
>>
>> You can also set
>>
>>      bool                                debugData;                 //!<
>> Print out some performance relevant information about the data
>>      bool                                debugPerformance;          //!<
>> Print out some performance information
>>
>>
>> in the MapParameter structure (via the setter) to get some debug
>> information.
>> --
>> 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 thought it was already done (doble buffer).... I'll turn debug variables
on to check what's going on.

Thanks for your answers.

I'll write back as soon as I get results or problems :-D



On Mon, 27 Dec 2021 at 15:04, Tim Teulings <ti...@fr...> wrote:

> Hello,
>
> > You can get inspiration in "client-qt" library. There are two kind of
> > renderer:
> >
> >   - tiled renderer - background thread is rendering map to tiles,
> similar as
> > online raster services, and they are composed to final map in UI thread.
>
> This allows to cache tiles and rendering of smaller than screen tiles
> (which is faster than rendering full screen). On the other hand
> composing the tiles sometimes results in local glitches.
>
> >
> https://github.com/Framstag/libosmscout/blob/master/libosmscout-client-qt/
> > include/osmscoutclientqt/TiledMapRenderer.h
> >
> >   - plane renderer - there are two map canvases. one owned by UI thread,
> > it is transformed (zoomed, moved) to expected coordinates and second
> canvas
> > that is used for rendering by background thread with updated projection.
> When
> > rendering is finished, these canvases are swapped.
>
> This would be a classic gaming double buffer technique. Or thing of a
> asynchronous rendering pipe where the UI sends commands to a background
> thread ands visualizes the results retrieved later on.
>
> Nevertheless, even if you did not implement it this way, rendering time
> should be correlated to the area moved. And small movements should not
> take multiple seconds.
>
> >
> https://github.com/Framstag/libosmscout/blob/master/libosmscout-client-qt/
> > include/osmscoutclientqt/PlaneMapRenderer.h
> >
> > We don't have such interactive renderer for GDI unfortunately.
>
> Which means, that there is only a client-qt library, but no "client" or
> "client-windows" library. It would likely possible to move parts of the
> client-qt library into a client library (to increase reuse) however the
> Qt library and especially signal-slot mechanism a relative invasive ;-)
>
> It would be interesting to see the content of your OnTileUpdate()
> method. I still assume that there is possible potential for optimization.
>
> You can also set
>
>      bool                                debugData;                 //!<
> Print out some performance relevant information about the data
>      bool                                debugPerformance;          //!<
> Print out some performance information
>
>
> in the MapParameter structure (via the setter) to get some debug
> information.
> --
> 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,

> You can get inspiration in "client-qt" library. There are two kind of
> renderer:
> 
>   - tiled renderer - background thread is rendering map to tiles, similar as
> online raster services, and they are composed to final map in UI thread.

This allows to cache tiles and rendering of smaller than screen tiles 
(which is faster than rendering full screen). On the other hand 
composing the tiles sometimes results in local glitches.

> https://github.com/Framstag/libosmscout/blob/master/libosmscout-client-qt/
> include/osmscoutclientqt/TiledMapRenderer.h
> 
>   - plane renderer - there are two map canvases. one owned by UI thread,
> it is transformed (zoomed, moved) to expected coordinates and second canvas
> that is used for rendering by background thread with updated projection. When
> rendering is finished, these canvases are swapped.

This would be a classic gaming double buffer technique. Or thing of a 
asynchronous rendering pipe where the UI sends commands to a background 
thread ands visualizes the results retrieved later on.

Nevertheless, even if you did not implement it this way, rendering time 
should be correlated to the area moved. And small movements should not 
take multiple seconds.

> https://github.com/Framstag/libosmscout/blob/master/libosmscout-client-qt/
> include/osmscoutclientqt/PlaneMapRenderer.h
> 
> We don't have such interactive renderer for GDI unfortunately.

Which means, that there is only a client-qt library, but no "client" or 
"client-windows" library. It would likely possible to move parts of the 
client-qt library into a client library (to increase reuse) however the 
Qt library and especially signal-slot mechanism a relative invasive ;-)

It would be interesting to see the content of your OnTileUpdate() 
method. I still assume that there is possible potential for optimization.

You can also set

     bool                                debugData;                 //!< 
Print out some performance relevant information about the data
     bool                                debugPerformance;          //!< 
Print out some performance information


in the MapParameter structure (via the setter) to get some debug 
information.
-- 
Gruß...
    Tim

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

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

Hi David. 

It is normal that data loading and rendering takes few seconds. It depends on 
zoom level and count of objects on the map. For interactive UI application, 
it is necessary that rendering in done in background, non-UI thread.

You can get inspiration in "client-qt" library. There are two kind of 
renderer:

 - tiled renderer - background thread is rendering map to tiles, similar as 
online raster services, and they are composed to final map in UI thread.

https://github.com/Framstag/libosmscout/blob/master/libosmscout-client-qt/
include/osmscoutclientqt/TiledMapRenderer.h

 - plane renderer - there are two map canvases. one owned by UI thread, 
it is transformed (zoomed, moved) to expected coordinates and second canvas 
that is used for rendering by background thread with updated projection. When 
rendering is finished, these canvases are swapped. 

https://github.com/Framstag/libosmscout/blob/master/libosmscout-client-qt/
include/osmscoutclientqt/PlaneMapRenderer.h

We don't have such interactive renderer for GDI unfortunately.

Lukas

Dne pondělí 27. prosince 2021 12:02:24 CET David Huelves Ramos napsal(a):
> Hello,
> 
> After compiling the libraries (thanks to Tim and Lukas for the help). I
> started to test the library.
> All I need is to use the drawing capability under windows desktop app. So I
> decided to take a look
> at DrawCGIMap demo. I modified it to take care of mouse drag to redraw the
> tile but speed is horrible. I'm sure I'm doing something wrong but I
> supposed the demo would draw the maps fast...
> 
> I left the demo as it is but adding the following:
> 
> [image: image.png]
> 
> Time refreshing the window is about 5-10 seconds... And I would like to be
> as smooth as google at least.
> 
> I can't identify where is the bottleneck... As I can't debug the libraries
> itself....
> 
> Any Suggestions?
> 
> Regards

[Libosmscout-development] GDI drawing Performance Under Windows

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

Hello,

After compiling the libraries (thanks to Tim and Lukas for the help). I
started to test the library.
All I need is to use the drawing capability under windows desktop app. So I
decided to take a look
at DrawCGIMap demo. I modified it to take care of mouse drag to redraw the
tile but speed is horrible. I'm sure I'm doing something wrong but I
supposed the demo would draw the maps fast...

I left the demo as it is but adding the following:

[image: image.png]

Time refreshing the window is about 5-10 seconds... And I would like to be
as smooth as google at least.

I can't identify where is the bottleneck... As I can't debug the libraries
itself....

Any Suggestions?

Regards

Re: [Libosmscout-development] Is there any Windows CGI demo available?

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

Now that I achieve the compilation..... :).

Is Import App Multiprocessor? As I ran it 2 hours ago and still
working......

Regards.

On Thu, 23 Dec 2021 at 16:13, David Huelves Ramos <dav...@gm...>
wrote:

> Thanks. I deduce it because of the x64 tag :-D
>
>
> Regards.
>
>
>
> On Thu, 23 Dec 2021 at 15:56, Tim Teulings <ti...@fr...> wrote:
>
>> Hello,
>>
>> the architecture (x86 or x64) for Visual Studio can be set via the -A
>> cmake option, see
>>
>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2016%202019.html
>> --
>> Gruß...
>>     Tim
>>
>>
>>
>> _______________________________________________
>> Libosmscout-development mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>
>

Re: [Libosmscout-development] Is there any Windows CGI demo available?

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

Thanks. I deduce it because of the x64 tag :-D


Regards.



On Thu, 23 Dec 2021 at 15:56, Tim Teulings <ti...@fr...> wrote:

> Hello,
>
> the architecture (x86 or x64) for Visual Studio can be set via the -A
> cmake option, see
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2016%202019.html
> --
> Gruß...
>     Tim
>
>
>
> _______________________________________________
> Libosmscout-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>

Re: [Libosmscout-development] Is there any Windows CGI demo available?

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

Hello,

the architecture (x86 or x64) for Visual Studio can be set via the -A 
cmake option, see 
https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2016%202019.html
-- 
Gruß...
    Tim

Re: [Libosmscout-development] Is there any Windows CGI demo available?

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

Got it

-DCMAKE_BUILD_TYPE=Release



On Thu, 23 Dec 2021 at 13:50, David Huelves Ramos <dav...@gm...>
wrote:

> I delete all the libos... directory and downloaded again.
>
> rebuild and now it works....
>
> don't ask me why.
>
> BTW: how could I compile the library for x86 release or x64 release?
>
> thanks for your patience and time.
>
>
>
>
> On Thu, 23 Dec 2021 at 11:19, David Huelves Ramos <dav...@gm...>
> wrote:
>
>>
>>
>> On Wed, 22 Dec 2021 at 20:06, Tim Teulings <ti...@fr...> wrote:
>>
>>> Hello David,
>>>
>>> getting closer...
>>>
>>>  From the code:
>>>
>>> #if defined(HAVE_LIB_PROTOBUF) ||
>>> defined(OSMSCOUT_IMPORT_HAVE_PROTOBUF_SUPPORT)
>>>          PreprocessPBF preprocess(callback);
>>>
>>>          if (!preprocess.Import(typeConfig,
>>>                                 parameter,
>>>                                 progress,
>>>                                 filename)) {
>>>            return false;
>>>          }
>>> #else
>>>          progress.Error("Support for the PBF file format is not
>>> enabled!");
>>>          return false;
>>> #endif
>>>
>>>
>>    At this point "libosmscout\build\Import\include"
>>    in the config file there is no PROBUF defined.
>>
>>
>>
>>> Frm Config.h (generated by build system)
>>>
>>> /* libprotobuf detected */
>>> #ifndef HAVE_LIB_PROTOBUF
>>> #define HAVE_LIB_PROTOBUF 1
>>> #endif
>>>
>>> and ImportFeatures.h (also generated, however only ocrrectly by the
>>> meson build system):
>>>
>>> /* *osm.pbf files can be imported */
>>> #define OSMSCOUT_IMPORT_HAVE_PROTOBUF_SUPPORT
>>>
>>> Can you please check your Config.h file
>>> (build/Import/include/osmscout/pivate/Config.h) if the macro is set.
>>>
>>>
>> [image: image.png]
>>
>>       I can't find any definition of
>> "OSMSCOUT_IMPORT_HAVE_PROTOBUF_SUPPORT"
>>
>>   any tip on this?
>>
>>
>>
>>> Is is also possible that it fails at runtime (e.g. protobuf is available
>>> but not libz) , but in this case it seems like the support was not build
>>> in while the necessary libraries itself seem to have been found.
>>>
>>> Is PreprocessPBF.cpp and also the *.pb.* (fileformat.pb.cc and Co.)
>>> beeing build?
>>>
>>> Also at the end of the initial cmake call a resulting sttaus is dumped:
>>>
>>> ...
>>> if (OSMSCOUT_BUILD_IMPORT)
>>>    message(STATUS " - libxml2 support:              ${LIBXML2_FOUND}")
>>>    message(STATUS " - protobuf support:             ${PROTOBUF_FOUND}")
>>>    message(STATUS " - C++17 parallel execution:
>>>  ${HAVE_STD_EXECUTION}")
>>> endif()
>>> ...
>>>
>>> What is show in your case? It is possible that the library is found but
>>> not the protoc executable (for whatever reasons) and the the resulting
>>> status is still false.
>>>
>>> Am 22.12.21 um 19:21 schrieb David Huelves Ramos:
>>> > Well,
>>> >
>>> > I get this:
>>> >
>>> > image.png
>>> >
>>> > So it seems libs are ok.
>>> >
>>> > Then I compile with "cmake --build ." and everything is ok.
>>> >
>>> > I get Import.exe
>>> > and libosmcout-import libraries
>>> >
>>> > image.png
>>> >
>>> > But again, and I don't know why:
>>> >
>>> > image.png
>>> >
>>> > when I try to Import a .ost.pbf file I get the same error message.
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, 22 Dec 2021 at 19:07, David Huelves Ramos
>>> > <dav...@gm... <mailto:dav...@gm...>> wrote:
>>> >
>>> >     It seems that I had to get into the build dir and specify -S .. to
>>> >     get it done.
>>> >
>>> >     now is working on: "cmake --build ." from inside the build dir.
>>> >
>>> >     I'll write you back after finished.
>>> >
>>> >     On Wed, 22 Dec 2021 at 18:55, Tim Teulings <ti...@fr...
>>> >     <mailto:ti...@fr...>> wrote:
>>> >
>>> >         Hello David,
>>> >
>>> >          > but don't know what does it mean.
>>> >
>>> >         First the warning above:
>>> >
>>> >         cmake likes to sepaeate the source directory and the build
>>> >         directory.
>>> >         Please create a build sub directory and call cmake from with in
>>> >         this sub
>>> >         directory (with .. as path to the root cmake file). This should
>>> >         make the
>>> >         warning go away.
>>> >
>>> >         You should also cleanup the root directory from everything that
>>> >         is not
>>> >         part of the git content and that you did not create yourself
>>> >         manually.
>>> >
>>> >         As you can see from the output from the latest Windoes Visual
>>> >         Studio
>>> >         build on github
>>> >         (
>>> https://github.com/Framstag/libosmscout/runs/4604314355?check_suite_focus=true
>>> >         <
>>> https://github.com/Framstag/libosmscout/runs/4604314355?check_suite_focus=true
>>> >
>>> >
>>> >         (see section "Confiure build project") the start off the cmake
>>> >         call is
>>> >         different:
>>> >
>>> >         1s
>>> >         3s
>>> >         8s
>>> >         1s
>>> >         1m 19s
>>> >         3s
>>> >         0s
>>> >         2s
>>> >         1s
>>> >         1s
>>> >         2m 15s
>>> >         Run cmake -G "Visual Studio 16 2019" -A x64
>>> >         -DOSMSCOUT_BUILD_DOC_API=OFF
>>> >         -DCMAKE_SYSTEM_VERSION=10.0.18362.0
>>> >
>>>  -DCMAKE_TOOLCHAIN_FILE=D:\a\libosmscout\libosmscout\vcpkg\scripts\buildsystems\vcpkg.cmake
>>> >
>>> >         -Wno-dev ..
>>> >         -- Selecting Windows SDK version 10.0.22000.0 to target
>>> Windows 10.
>>> >         -- The C compiler identification is MSVC 19.29.30138.0
>>> >         -- The CXX compiler identification is MSVC 19.29.30138.0
>>> >         -- Detecting C compiler ABI info
>>> >         -- Detecting C compiler ABI info - done
>>> >         -- Check for working C compiler: C:/Program Files
>>> >         (x86)/Microsoft Visual
>>> >
>>>  Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe
>>> >
>>> >         - skipped
>>> >         -- Detecting C compile features
>>> >         -- Detecting C compile features - done
>>> >         -- Detecting CXX compiler ABI info
>>> >         -- Detecting CXX compiler ABI info - done
>>> >         -- Check for working CXX compiler: C:/Program Files
>>> (x86)/Microsoft
>>> >         Visual
>>> >
>>>  Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe
>>> >
>>> >         - skipped
>>> >         -- Detecting CXX compile features
>>> >         -- Detecting CXX compile features - done
>>> >         -- Looking for dlfcn.h
>>> >         -- Looking for dlfcn.h - not found
>>> >         -- Looking for fcntl.h
>>> >         -- Looking for fcntl.h - found
>>> >         -- Looking for inttypes.h
>>> >         -- Looking for inttypes.h - found
>>> >         -- Looking for memory.h
>>> >         -- Looking for memory.h - found
>>> >         -- Looking for stdint.h
>>> >         -- Looking for stdint.h - found
>>> >         -- Looking for stdlib.h
>>> >         -- Looking for stdlib.h - found
>>> >         -- Looking for strings.h
>>> >         -- Looking for strings.h - not found
>>> >         -- Looking for string.h
>>> >         -- Looking for string.h - found
>>> >         -- Looking for sys/stat.h
>>> >         -- Looking for sys/stat.h - found
>>> >         -- Looking for sys/time.h
>>> >         -- Looking for sys/time.h - not found
>>> >         -- Looking for sys/types.h
>>> >         -- Looking for sys/types.h - found
>>> >         -- Looking for unistd.h
>>> >         -- Looking for unistd.h - not found
>>> >         -- Looking for C++ include codecvt
>>> >         -- Looking for C++ include codecvt - found
>>> >         -- Looking for stddef.h
>>> >         -- Looking for stddef.h - found
>>> >         -- Check size of int16_t
>>> >         -- Check size of int16_t - done
>>> >         -- Check size of int32_t
>>> >         -- Check size of int32_t - done
>>> >         -- Check size of int64_t
>>> >         -- Check size of int64_t - done
>>> >         -- Check size of int8_t
>>> >         -- Check size of int8_t - done
>>> >         -- Check size of long long
>>> >         -- Check size of long long - done
>>> >         -- Check size of uint16_t
>>> >         -- Check size of uint16_t - done
>>> >         -- Check size of uint32_t
>>> >         -- Check size of uint32_t - done
>>> >         -- Check size of uint64_t
>>> >         -- Check size of uint64_t - done
>>> >         -- Check size of uint8_t
>>> >         -- Check size of uint8_t - done
>>> >         -- Check size of unsigned long long
>>> >         -- Check size of unsigned long long - done
>>> >         -- Check size of wchar_t
>>> >         -- Check size of wchar_t - done
>>> >         -- Looking for fseeko
>>> >         -- Looking for fseeko - not found
>>> >         -- Looking for mmap
>>> >         -- Looking for mmap - not found
>>> >         -- Looking for posix_fadvise
>>> >         -- Looking for posix_fadvise - not found
>>> >         -- Looking for posix_madvise
>>> >         -- Looking for posix_madvise - not found
>>> >         -- Looking for mallinfo
>>> >         -- Looking for mallinfo - not found
>>> >         -- Found PkgConfig: C:/Strawberry/perl/bin/pkg-config.bat
>>> (found
>>> >         version
>>> >         "0.26")
>>> >         -- Could NOT find MARISA (missing: MARISA_INCLUDE_DIRS
>>> >         MARISA_LIBRARIES)
>>> >         -- Found LibXml2:
>>> >
>>>  D:/a/libosmscout/libosmscout/vcpkg/installed/x64-windows/debug/lib/libxml2.lib
>>> >
>>> >         (found version "2.9.10")
>>> >         -- Found Protobuf:
>>> >
>>>  optimized;D:/a/libosmscout/libosmscout/vcpkg/installed/x64-windows/lib/libprotobuf.lib;debug;D:/a/libosmscout/libosmscout/vcpkg/installed/x64-windows/debug/lib/libprotobufd.lib
>>> >
>>> >         (found version "3.15.8")
>>> >         -- Found ZLIB:
>>> >
>>>  optimized;D:/a/libosmscout/libosmscout/vcpkg/installed/x64-windows/lib/zlib.lib;debug;D:/a/libosmscout/libosmscout/vcpkg/installed/x64-windows/debug/lib/zlibd.lib
>>> >
>>> >         (found version "1.2.11")
>>> >         ...
>>> >
>>> >         Please show the start of your call output. I would like to see,
>>> >         if SDK
>>> >         and compiler were correctly found. If not, there is a script
>>> in the
>>> >         Visual Studio compiler installation to be called (See for
>>> example
>>> >
>>> https://stackoverflow.com/questions/55097222/vcvarsall-bat-for-visual-studio-2019
>>> >         <
>>> https://stackoverflow.com/questions/55097222/vcvarsall-bat-for-visual-studio-2019
>>> >).
>>> >
>>> >         --
>>> >         Gruß...
>>> >              Tim
>>> >
>>> >
>>> >
>>> >         _______________________________________________
>>> >         Libosmscout-development mailing list
>>> >         Lib...@li...
>>> >         <mailto:Lib...@li...>
>>> >
>>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>> >         <
>>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development>
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Libosmscout-development mailing list
>>> > Lib...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>>
>>> --
>>> Gruß...
>>>     Tim
>>>
>>>
>>>
>>> _______________________________________________
>>> Libosmscout-development mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libosmscout-development
>>>
>>