Makpaint.. sloooow

BlitzMax Forums/BlitzMax Beginners Area/Makpaint.. sloooow

Snarty(Posted 2005) [#1]
Hi, any reason the makpaint example is pathetically slow. Before you ask, no build options are selected (ie not debug build). Makes no difference either way though.

Spec in sig


Perturbatio(Posted 2005) [#2]
driver related maybe? it runs fine for me.


Snarty(Posted 2005) [#3]
No idea, latest Catalyst drivers. Every other OpenGL program I run is fine. Could be driver related, though a bit of an "easy way out".

Oh, plus some more "complex" examples run very smooth, and fast.


BlitzSupport(Posted 2005) [#4]
Welcome back Snarty!

I'm on basically the same card and it's running properly for me.


QuickSilva(Posted 2005) [#5]
Mak Paint, I do not have that example. Where is it?

Jason.


Snarty(Posted 2005) [#6]
Thanks James :)

Hmm, no idea then.


Perturbatio(Posted 2005) [#7]
incidentally, I don't seem to have the makpaint sample in 1.09, I had to use it from 1.06


Snarty(Posted 2005) [#8]
I've uploaded it for those who don't have it.

http://snarty.f2o.org/examples/makpaint.zip


Snarty(Posted 2005) [#9]
Ok, I just added an fps counter, and without moving/drawing anything, it's running at 2fps, something is clearly very, very wrong!

Or is it that Pixmaps are generally a no-no for real-time stuff?


Dreamora(Posted 2005) [#10]
Pixmaps are most for creating OpenGL textures and grabbing, but they are about 10 to 100 times slower in drawing than TIMAGE


Snarty(Posted 2005) [#11]
Ahh, so this is generally a bad example of how to "pratically" use pixmaps. :)

Hence why it no longer appears in the examples with the dirsto I guess.

I'm guessing it's still possible to create a memory block representing image data and block copy to the backbuffer? (at a minimum of B+ speeds)


BlitzSupport(Posted 2005) [#12]
They're not generally a good idea for heavy realtime pixel manipulation, but that still doesn't stop it running smooth as silk here.

You can't directly access the back buffer memory in 'plain' OpenGL as far as I'm aware. Perhaps with extensions it's possible...


Snarty(Posted 2005) [#13]
Just out of interest James, are you using the same Catalyst drivers as me? (5.3)

I guess it could be the fact I run PC100 ram, but, if that were the case ProPixel would crawl on my machine since that is 100% system ram rendering.


Floyd(Posted 2005) [#14]
Works fine here, even with debug on.

I have the same speed CPU and RAM as you and graphics card is much worse.


Perturbatio(Posted 2005) [#15]
I don't know how accurate this is (nor whether it could be more efficient), but I only get 1fps more when drawing directly to the backbuffer (via plot).




Snarty(Posted 2005) [#16]
Well, this is just plain annoying then! If I take out the main DrawPixmap pic, 0, 0 it obviously runs full pelt. But why on earth is my system choking on drawing these "pixmaps" or what ever they really are.


Snarty(Posted 2005) [#17]
Ok, I tested your "plot" test, and it gave me 10fps (4 fps with debug on), for both tests. So, that screws things up royally, considering your system is far, far faster than mine. Go figure!


Perturbatio(Posted 2005) [#18]
I should point out that I only get 20fps with the first test and 21fps with the second.


Snarty(Posted 2005) [#19]
Any word on a "technical" front would be appreciated here. As this really needs addressing before I consider coding anything.

What could possibly be causing such a dramatic slowdown? Do I need to be wearing special socks or something? (as this is about as good guess as any from the feedback so far).


ImaginaryHuman(Posted 2005) [#20]
DrawPixmap renders using the CPU, not the graphics card hardware, because it has to transfer the pixmap data over the graphics-card bus every time you render it. It's the same as uploading a texture. You would be better off turning the Pixmap into an IMAGE, and then using DrawImage - on my system for example DrawImage is at least 10x faster than DrawPixmap.


ImaginaryHuman(Posted 2005) [#21]
So Snarty, are you considering writing a new paint package in Max?


Snarty(Posted 2005) [#22]
I may be migrating ProPixel to BMax, though it certainly wouldn't be full screen and I would probably stick to using DIB's as these are fast enough.

Btw, no idea who coded that macpaint thing. I personally wouldn't use pixmaps considering the appauling performance. Must be some very "odd" code which pushes the data to the graphic's memory. Never known anything so slow. (sorry, yes I have, plot in Spectrum BASIC :p )


ImaginaryHuman(Posted 2005) [#23]
Yeah if you use DrawPixmap it uses the CPU to move the data over the bus at draw-time. It's much better to cache the image on the graphics card as a texture/`image`.

Why wouldn't you be able to do a fullscreen paint program? What is a DIB?


Snarty(Posted 2005) [#24]
DIB's (Device independant Bitmaps) are what Windows friendly applications use to store graphics data in system memory, manipulate it using the system bus (usually faster) then dump to graphics memory. In the case of Windows API you can BitBlt to a selected DC (Device Context) with a few hardward tricks.

ProPixel currently uses BlitzPlus' flag 4 images (which I'm guessing are also DIB's, or System memory DirectDraw surfaces). This method is really fast, why the same performance is not available in BlitzMax is beyond me. I'm a little disheartend currently, but then I've not had a play with Max myself, just ran some examples (general image stuff is very nice), but got to my favourite example, memory manipulation (system > vid) and oh dear.

Sigh..


Dreamora(Posted 2005) [#25]
Thats because the way OpenGL works. It has simply no surfaces as DirectX has which has to do with the fact that it does not have any 2D at all like DirectX.

But Mark mentioned a DirectX7 module for 2D so hopefully this kind of problems will be over, at least on windows.


ImaginaryHuman(Posted 2005) [#26]
You could probably get around all the issues by just coming up with a different way to implement things under OpenGL. If you can work with hardware textures they are going to be plenty fast enough. It is only in areas of `reading data` that OpenGL isn't entirely friendly, like reading the backbuffer.


Snarty(Posted 2005) [#27]
Ok, sorted the problem, and in a way I'm glad the problem existed in the first place.

The problem? I needed to re-install my AGP drivers as they had reverted back to PCI mode.. sigh. Runs full speed now. :)

If anyone else has slow pixmaps in the future, check dxdiag > Display and if AGP Texture Acceleration is disabled or greyed out this will cause slowdown. Go in to Device Manager and update the PCI driver to an AGP one.