Design Approach

[jvcleave]

welcome @procedural !

One thing I am thinking design-wise is to move the ofAddListener stuff into setup() as opposed to the constructor.

A lot of times when I use GUIs is just to debug and the way it is now we are kinda strapped in with the constructor.

The other thing is just to use the ImGui namespace (at least in any examples/demos) unless the ui:: namespace has extra stuff. This way people can just copy and paste existing ImGui example code without have to change it.

[ghost]

Hey! :)

One thing I am thinking design-wise is to move the ofAddListener stuff into setup() as opposed to the constructor.

Well, I kinda like the opposite _because I'm too lazy to call .setup() function_ in every new ofApp :D

A lot of times when I use GUIs is just to debug and the way it is now we are kinda strapped in with the constructor.

What's the downsides of being strapped to the constructor? Genuine question, I'm unaware of any! I suck at C++ bullshits tbh! :D

The other thing is just to use the ImGui namespace (at least in any examples/demos)

_I'm too lazy to press shift key two times for capital letters_ :D Yeah, I'm one lazy fuck!

I saw ui:: is used in Cinder block for imgui...

This way people can just copy and paste existing ImGui example code without have to change it.

ImGui:: is still there! ui:: is just another alias.

[jvcleave]

Downsides of being strapped into the constructor are that those Events are being listened for/processed even though you may not be using the GUI. It's probably minimal (and can be avoided by just using a pointer).

Yeah - I saw that ImGui:: is still there. I was mainly talking about example code (feel free to type ui:: all you like :)

Looking forward to trying out the changes - would love to know if it works on mobile.

[ghost]

@jvcleave oh, didn't know that... Yeah, that changes everything, we should move stuff to setup then...

Sure, for examples we can stick to ImGui::! These were written within 2 minutes :D

I probably broke things for ES..

---

I myself have only one design thought:

ofImage img_button;
img_button.load("youtube.png");
tex_button = m_ui.loadTextureImage2D(img_button);

Wtf we should call my custom function to copy data from ofImage to GL texture when ofImage has one already: img_button.getTexture().getTextureData().textureID? This one doesn't work. I guess this question should be asked to a OF developer(s?), but still, jeez...

[ghost]

By the way, I remember profiling my ofxFirstPersonCamera addon, I didn't saw any hot areas in POCO's function scheduler, class cache misses were the slowest thing of simplest examples... I dunno, maybe if you load, like, 100 addons and every addon will have setup in the constructor, maybe it'll be noticeable, but I didn't experienced issues like that yet...

[jvcleave]

Did you mess with trying to use ofTexture instead of ofImage to load?

[ghost]

Did you mess with trying to use ofTexture instead of ofImage to load?

I didn't found a way to load things on ofTexture, maybe it's because ofTexture is a representation of a texture on GPU side, and to get there raw data should be uploaded via ofBuffer?.. Dunno. I tried ofBuffer too, same thing.

[jvcleave]

It's deceiving but can load directly into an ofTexture with

ofTexture texture;
ofLoadImage(texture, "yourImage.png");

There may be an ofTexture::load now but the above is how I am used to doing it

[ghost]

@jvcleave just tested it, nope, it renders the same fully white square instead of a texture.

[jvcleave]

Yeah - ES2 isn't currently working

I am wondering if it makes sense to break out each implementation and share a common interface. I find it can be easier to work on without fear of breaking other implementations you can't test yourself

e.g.

ofxImGui.cpp
RPI_GLRenderer.cpp
RPI_ProgrammableRenderer.cpp
GLFW_Renderer.cpp
etc.

I'll mess around with ES2 and see where it leads

[jvcleave]

Check out the develop-jvc branch - I just did a couple of things in order to (hopefully) help cross-platform/renderer support

Created a GLFW_Engine class. This is basically the work that you did. It extends BaseEngine which is just the interface (something I will need to implement for ES2).

What this allows is me to re-implement RPi support without needing GLFW. There will also be no need for #ifdef TARGET_OPENGLES, etc

I broke out the Style into a Style_Cinder.h file. This way someone can easily write a separate style and pass it into setup to be applied (or apply it later)