Efficient way to render one-byte-per-pixel data

Currently I use a loop to create the normal ARGB data that BitmapData expects, which is very CPU intensive.

In GL I could possibly do it using glTexImage2D with GL_RED as the format, and copy the red value to green and blue in the shader.

Can I upload my one-byte-per-pixel data directly to GPU with OpenFL?

2 Likes

I wrote on StackOverflow:

You can look at the “TextRendering” sample from the Lime project to see an example of rendering from only an alpha texture. As of writing, this is not inherently support in OpenFL’s renderer, but a pull request to this effect would be welcome.

The alternative would be using an OpenGLView with code similar to the “TextRendering” sample.

Happy to talk more :wink:

Thanks for the direction!

But it is a bit more low level than I expected. Luxe engine has a pretty good API for stuff like this. But I can understand that a GPU friendly API isn’t the top goal of OpenFL . I will try to work this out. Thanks again!

The Lime ImageBuffer type supports single-channel surfaces, but OpenFL BitmapData expects 32-bit buffers, we just need to add some support in OpenFL for them, to make it simple.

We aren’t real far off, I think it’s mostly a matter of gl.ALPHA instead of gl.RGBA for the upload format

Hi again!

I’m working on a new API to replace OpenGLView, I’m interested in your feelings about it. Here’s a sample project:

https://github.com/openfl/openfl-samples/tree/master/haxelib/features/display/SimpleAbstractView

In the interim (before we add single-color texture support), using the AbstractView API should make it easier to do what you need.

If you check it out, let me know what you think about the naming, and how it works

1 Like

Yes it looks easier and play nice with the display list.

However, I just tried to embed your sample code to my project and I noticed that when the renderGL function gets called my other display objects are gone. Are there any missing cleanup calls?

Fixed the sample and the implementation, should be able to mix with other display objects now :slight_smile:

Yeah it is working nicely now

A couple changes, I renamed AbstractViewEvent to RenderEvent, and also made it so that AbstractView will render only when dirty. If you need to update the contents (other than changing an alpha, x, y or other transform value) call the new invalidate () method to mark the content as dirty :slight_smile:

This way, we can stop flipping the buffers when content hasn’t changed, it will also help later when we get into GL-based bitmapData.draw for render-to-texture