Render test

[OgreTransporter]

Hi,

i wrote a script (https://gist.github.com/OgreTransporter/5b1e389c23cb5e871dd05ebf2a56a166) to try out and compare all renderers. The result can be found under https://drive.google.com/file/d/1xtHHJkckKghlqV5m7mYSftgizqFpbJwJ/view?usp=sharing. But I noticed some problems. The OpenGL renderer does not work for me at all. Furthermore I could not import some PBFs (Geofabrik e.g. spain-latest, us-midwest-latest, us-northeast-latest, us-south-latest, us-west-latest) - the import was aborted with error messages.

[Framstag]

Hi @OgreTransporter (and hi @Karry :-)). This is interesting and helpful work. I personally would like to have such script for Linux (or better a small C++ application) but I take what I get :-)

The OpenGL in principle works (if not broken by refactoring) but has for example font problems (bg/little . It is possible that the result under Linux would be (slightly) better. I have never checked what happens under Windows but assume initialisation problems. From a brief look is seams like the Cairo renders differently regarding font type and size (have you compiled cairo with pango?) and also does not seem to have overlays enabled.

Colors seems to be slightly different between renderings? Else the rendering look rather similar - with the GDI+ backend looking as good as all others.

The first Qt renderings look strange?

I assumed that @Karry is from time to time importing all major countries for his app,so I'm surprised that some countries do not import. The import should never abort, so this is per definition a bug, Please make a ticket!

[Karry]

Interesting results :-) I am just curious, what was happening to Qt renderer during low zoom at Germany? It is reproducible? Can you send us arguments used for these runs?

And to importer, create issue for it please. I am importing whole planet ~monthly (on Linux) and there are no issues... Databases are downloadable from http://osmscout.karry.cz/ website. There are import logs and html reports also. OSMScout2 demo contains simple downloader:

[Karry]

To importer, are you building 32 bit or 64 bit version? Importer requires huge amount of memory. I would be worry to use 32 bit binary for it...

[Framstag]

The spain import worked for me. Do you make the import under Windows? VisualStudio based build or MSYS based? 32 or 64 bit (as asked by Lukas)?

[OgreTransporter]

That are a lot of points ;-)

I can also build a C++ program for testing, which will run under Ubuntu and Windows - I can't test anything else.

OpenGL does not work for me at all. But I can test it on another Windows system. Yes, I am not using pango right now. This seems to cause problems. Maybe pango should be set as a required dependency and not optional anymore.

I stopped working with 32 bit already two years ago. Everything is built with 64 bit and Visual Studio 2017 and 2019. That the importer uses a lot of memory is new to me. I would be happy if it uses CPU, RAM and hard disk to full capacity, but at least it doesn't work under Windows. Edit: #959

[Framstag]

@OgreTransporter Since you have created a new issue for the import problem, please make sure what the topic of this issue is. Else we might have problems, fixing the right stuff...

[OgreTransporter]

@Framstag This issue is more for information than for debugging. But I have opened new issues for several points:

• Importer Import problems #959
• render test tool render test tool #960
• OpenGL on Windows OpenGL on Windows #961
• DirectX character encoding DirectX character encoding #962

[Framstag]

@OgreTransporter : Thanks should we close this issue then?

[OgreTransporter]

@Framstag Do what you want ;-)

[Framstag]

Sorry, I do not want to be rude, I just try to keep the number of tickets low and the quality of each ticket hight. I have the feeling there are too many Open-Source project out there, where the number of issues feels like "out of control".