Sanctimonia says:

Thanks for the completely thorough response. Wow. 🙂

“Not sure about that, people tend to not like external commits.”

From what I’ve seen (I read the user and dev mailing lists every day), Benoît really does love people helping, both with bug reports and code contributions. It’s a big project with a big user base, and all the users are programmers too. I’ve never really seen him get snooty or pissed, even when others throw the rare tantrum. To be safe simply sending an email to the mailing list (which I could do) with the patch and explanation would probably be all it took to get it included. I could even add an example project to show that it works. If formatting or other convention deviations were an issue he or another dev (at least two others are interested in OpenGL and SDL) could make the code compliant.

“That really depends how the surface is defined. Generally it is done at the creation of the SDL surface. So if it is software based, you are correct. Otherwise, if it is already in video ram, there is nothing to be done. You’d have to look at how Gambas creates their surfaces.”

I think the SDL surface used as the rendering window is created in hardware by default and without option, but that GAMBAS allows copying images in system memory to the surface. A bit of a hardware/software hybrid to preserve component method interoperability, especially considering there isn’t much “hardware” there. I researched the Window and Screen classes and they have no properties for controlling whether they use hardware or software. Laurent had this to say about SDL:

“SDL 1.2.x library itself isn’t hardware accelerated under linux. The SDL component use only the SDL library to keep window/images in RAM, but all drawing in the window is done with OpenGL (using texturing), so image are cached (send only one time in the VRAM). If you modify the Image continuously, the Image will need to be load in VRAM before displaying continously also.

Currently blitting image to image is slow because done in software, but i’ve plans to do this with OpenGL (so in VRAM directly) through the Framebuffer Object extension.”

He didn’t say how “the Image will need to be load in VRAM before displaying continously”, probably because it’s not possible right now.

As I understand it he also told me that SDL was basically a wrapper for OpenGL that provided basic blitting functionality. GAMBAS has what appears to be pretty robust OpenGL support, though I’m not sure how that relates to expanding the functionality of its SDL component (I’m guessing it could only make it easier). Here is the documentation for the OpenGL and SDL components, etc., that are currently supported:

gambasdoc.org/help/comp?v3

Docs in italics with a prepended ./ are not yet documented.

It doesn’t matter to me if I use SDL or OpenGL as long as I’m able to hardware accelerate operations like blitting, scaling, and rotation in a way that is compatible with native software methods such as DrawAlpha. OpenGL is extremely low level, so if I used it directly I’d need to create procedures that accomplish the basic functions I require, effectively hiding the low level nature of OpenGL to avoid a complete rewrite of the rendering engine.

“That is correct except if the surfaces are created in video ram from the start.”

I think the only surface created in video RAM is the render window/screen. There’s basically only one SDL surface from what I can tell.

“Well technically this isn’t really necessary. Normally, SDL allows you to do double buffering, so you’ve got that buffer, it is the screen surface. When you flip, you go from one to the other.”

I might be able to pull things off with only two surfaces, but the compositing of the various layers is pretty complex and involves multiple sublayers of varying sizes. Even so, I don’t think the current SDL implementation supports double buffering. I tried to create two screens once just for that purpose and it wasn’t too happy about it. I don’t think the surface supports read operations either, so ultimately I’d be using images in RAM as the source for a write.

“It really depends, benchmarking would be necessary to assess that. It could but it might not. Generally, it’s better to first reduce the number of blits you are doing, then worry about this.”

That is true and I agree completely. Believe me that I don’t write inefficient code and wonder why it’s slow. If I do I always optimize it later, even if it requires a major overhaul or changes in logic. I’ve done everything I can to make things more efficient short of removing major features. I have compared FPS rates between experiments extensively. What’s killing me is software scaling, rotation, and image-to-image blits. The fastest thing I can do is blit an image directly to the window/screen surface, which is passing an image in RAM to an image in video RAM. Often this is accompanied by software scaling and/or rotation, which really kills the frame rate (even on small images).

“Have you thought of threading, parallelizing the code, etc. ?”

I have, though mostly for the server and not the rendering engine. I might be able to do it with the rendering engine, though I’d have to run multiple GAMBAS applications (currently no native support for multithreading) and figure out some way to get them communicating (maybe local loopback network interface or the file system to pass image pointers and completion states). That’s something I’d consider once hardware acceleration was working and were I to need abnormally large resolutions to be rendered (greater than 1920×1080).

“Like I said, if you request the SDL surface to be in hardware, then it’s the runtime’s decision to put it there or not.”

I’m pretty sure it is in hardware by default, as image-to-surface blits are much faster than image-to-image blits. Sadly there are no options when creating a window/screen using the SDL component, or properties to determine if it is in hardware or software.

“Now that’s way more tricky. Are you doing SDL or OpenGL ? You can’t really mix them up that easily. Normally, people either do SDL with blitting, flipping, etc; or they do SDL + OpenGL, using SDL to open the window and handle events and do pure OpenGL code for the rendering. I, for example, do the latter.”

I think the GAMBAS SDL component implementation is extremely barebones from Laurent’s apologies and limited functionality. I think he’s created a hybrid of a partial SDL implementation using OpenGL as the backend for its operations.

“As far as I know, I don’t see how you would mix SDL blitting + OpenGL except to do this:

– Prepare your SDL image
– Blit what you want on it

But then, if you’re using OpenGL, you have to:
– Generate an OpenGL texture
– Send off the SDL image to the OpenGL back end
– Do your OpenGL code to make it the new image

The passage between SDL and OpenGL will be costly to the point that you will be crying.”

Hmmm. I think I don’t know enough about the relationship between SDL and OpenGL. My understanding is that it’s an OpenGL/DirectX wrapper with event handling as you mentioned. They should go hand in hand, whether transparently or explicitly (though I seriously don’t know shit about them so please excuse me!). I think the SDL component implementation is doing what you’re saying transparently, but in a severely limited way.

“If by scaling you mean changing the size of the images, this is automatic as long as they are OpenGL textures. There is nothing to be done here. However, this brings me back to my previous point.”

That would be true except that currently images seem to be created in software, scaled and rotated in software, and finally written to the SDL window/screen surface which is in hardware and using OpenGL. Maybe the properties of the window/screen surface could be extended to the creation of images (Dim someimage As Surface = New Surface[128, 128]), so they could be written to each other using regular OpenGL texture methodology.

“Basically, from what I can tell, you want performance. To get that performance, you surely will have to change the way you do your rendering. Either by blitting much less, or going into a OpenGL way of doing things which is generally highly different than what would be done in a pure SDL world.”

Right now I’m doing a reasonable number of straight image blits, a small number of scaling and rotation functions via normal image methods, and a moderate number of DrawAlpha methods which must be done in software. The DrawAlpha method is extremely fast, so that is perfectly acceptable. What’s killing me are the straight blits, scaling and rotations.

From what I gather from your comments, my feeble conjecture and Laurent’s comments, we’re working with possible incompatibilities between SDL’s accelerated operations, OpenGL’s accelerated operations and GAMBAS’s software image operations. What’s a mystery to me is how the SDL component of GAMBAS apparently uses OpenGL to perform its window/screen writes while maintaining interoperability with GAMBAS’s software methods such as DrawAlpha. The supposedly interoperable (though limited) relationship between GAMBAS’s native image processing, SDL and OpenGL may be the glue that binds these areas together.

Maybe I should shoot this thread to Benoît and Laurent to see what their input is?

And now to end what has taken me longer to write than any post or reply in my life! Holy crap. 🙂