Slow image drawing

[jacdelad]

Hi,
I have an image which is painted into a texture (yes, code not runnable, but enough to show what I mean):

Code: Select all

    StartDrawing(TextureOutput(#Texture_Top))
    DrawImage(ImageID(Image),0,0)
    StopDrawing()

Nothing special...
Now, the picture is 11600*7400 pixel huge, which is huge. Painting takes about 10 seconds on a fast computer. Is there a way to speed this up?

[STARGÅTE]

Do you know fore sure that drawing of the image is slow?
Couldn't it be the load up of the non-quadratic texture into the graphic card buffer?

What time you get, when you load the huge texture with LoadTexture()?
What is the time, if you draw the image twice? 20 s or less?

[jacdelad]

This led to some interesting observations:
I put Debug-commands between all operations. DrawImage is indeed fast, but the debug before and after StopDrawing() needed a lot of time. Is this normal?
Doubling the StartDrawing()/StopDrawing() block doubled the time needed.
Also, when working with huge pictures, the second StartDrawing() crashes the program; using smaller pictures it works.
And I don't know whether the shape of the texture has an impact, I need to create a sample for loading quadratic textures...

I can't test with LoadTexture, because I don't know how to save it?!

[mk-soft]

Does it even make sense to create a texture with a pixel size of 11600x7400? That is always 327 megabytes.
I don't know of any monitor with this resolution.

[jacdelad]

I think so: It's my PCB. You can zoom in and there's a big difference between low and high resolution:

[pf shadoko]

can you compare with directx9 ?

[RASHAD]

Don't use zoom or scale with the originals
1- Copy the original to another image
2- Increase or decrease the scale with respect to the current scale
3- Apply the new scale to the copied image

That mean you must keep the original intact

[jacdelad]

Ok, so I'm confused:
Choosing "OpenGL" says the subsystem is invalid.
Choosing "DirectX11" let's the 3D-engine fail on initialization.
Choosing "DirectX9" works and seems to be only working mode. So I assume this is what I was using all the time???

I have a meeting in some minutes, so I won't be able to test something until thursday...

[Fred]

Without subsystem it uses OpenGL

[jacdelad]

Ok, so I was able to test it:
With OpenGL it needs 20 seconds.
With DirectX9 it needs 5.6 seconds, but the board is skewed (though there's no change within my program, other than defining the subsystem).

I'll look into it further on thursday.

BTW: I was not aware I could change the subsystem, because the help states Note: 3D engine no more available as it uses OpenGL for DirectX 9/11. This may be the reason why the initialization of the engine fails with DirectX 11, but the way I understand it, it shouldn't work with DirectX 9 too.
https://www.purebasic.com/documentation ... stems.html

[pjay]

I don't know if you resolved this, but that size texture could be stretching the capabilities of the GPU/Driver; it may be falling back into some kind of compatability mode, hence the slowness.

Try breaking your texture up into multiple smaller textures (i.e. 1024x1024) and modifying your underlying mesh to suit

[jacdelad]

Hi pjay,
unfortunately I'm still investigating. I found out that using DX9 ist significant faster, but my textures are stretched on the x-axis (why not the y-axis=???). So I reverted this for now.
My PCB is only one polygon which is stretched into shape (the PCB is basically a very flat cuboid). Would splitting it into multiple polygons affect performance negatively? Also I'm still clueless why exactly all the time is used for StopDrawing().

Finally, it looks like I'll quit my job soon to start somewhere else (with much better conditions, of course). So, for the moment I maintain the existing (and working) programs to leave them in a running condition for my current employer. The PCB project, Gerber and such will die in this case, because my new job will be network administration and user support, not programming optical inspection machines...