OpenGL ES in FLTK

[rageagainstthebath]

Hello,

I am completely new to FLTK, OpenGL and GUI programming in general. It's a hobby project.

I'd like to write a program that shows some windows rendered in GPU (fast, antialiased 2D plots with millions of data points). I have created an experimental build based on demo OpenGL code in FLTK 1.4.0 and I like how it works. It even works in Wayland (weston, at least).

I haven't had an opportunity to test it on ARM platform yet, but as far as I can tell it may not work unless it's OpenGL ES code. I also read that Wayland supports OpenGL ES only at the moment, yet somehow it works.

I wish to use this program for a long time, so I want to future proof it with Wayland and GL ES support (i may be using ARM machines in the future). So my questions are: does my Wayland experiment confirm that OpenGL ES does indeed work, and if not, what are the changes necessary to build a "truly" OpenGL ES program? Is OpenGL ES even supported by FLTK? I couldn't find any evidence for this.

My understanding is that OpenGL ES is a strict subset of OpenGL, so is this enough to simply avoid features not covered by ES?

Thank you in advance for your time and patience.

Tom

[Matthias Melcher]

The CPU has not much to do with OpenGL support. I run FLTK with standard OpenGL on an ARM CPU with macOS, Linux for ARM (X11 and Wayland in a virtual machine, as well as Raspberry Pi with 32 bit ARM Raspbian Linux X11 and Wayland), and even on MS Windows 11 for ARM. There is no need to "downgrade" to OpenGL ES.

OpenGL ES is for embedded systems (that's what the ES stands for), and many embedded systems use 32 and 64 bit ARM. FLTK  does not currently target embedded systems, but SDL2 support is in the works, which in turn runs on OpenGL ES systems.

[Bill Spitzak]

My vague understanding is that a Wayland server is limited to GLES to actually update the display. However the buffers containing pixels to put into the windows can be drawn by anything, including full OpenGL, Vulkan, Cairo, etc.

On Tue, Aug 15, 2023 at 2:44 PM 'Matthias Melcher' via fltk.general <fltkg...@googlegroups.com> wrote:

The CPU has not much to do with OpenGL support. I run FLTK with standard OpenGL on an ARM CPU with macOS, Linux for ARM (X11 and Wayland in a virtual machine, as well as Raspberry Pi with 32 bit ARM Raspbian Linux X11 and Wayland), and even on MS Windows 11 for ARM. There is no need to "downgrade" to OpenGL ES.

OpenGL ES is for embedded systems (that's what the ES stands for), and many embedded systems use 32 and 64 bit ARM. FLTK  does not currently target embedded systems, but SDL2 support is in the works, which in turn runs on OpenGL ES systems.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/4dc97ad4-5c06-4df6-95e6-e56dd367849bn%40googlegroups.com.

[rageagainstthebath]

Thank you for your answer, it is very helpful. 

That is certainly good to know that all these scenarios worked for you, I think I may safely proceed with my current approach - plot stuff with OpenGL and not worry about anything.

Are you sure that in all these cases, the graphics were actually rendered in GPU? Or there is a possibility that fallback to CPU rendering kicked in?

I was also considering Cairo but I'm not sure if it attempts rendering in GPU.

I am aware that ES stands for embedded systems. I would appreciate if you could tell me what do you consider one and why FLTK needs special treatment for this use case.

Is it a lack of display server, perhaps? Surely not CPU architecture. I've work with both x86 lab instruments and ARM workstations.

[Matthias Melcher]

We currently support Linux, macOS, and Windows. Our Fl_GL_Window uses the OpenGL API of the underlying OS. For FLTK, neither the CPU nor GPU has any relevance. It's up to the operating system and the driver setup to decide if rendering goes via GPU or software emulation. FLTK provides an API to set some aspects of the OpenGL window as described here: https://fltk.gitlab.io/fltk/classFl__Gl__Window.html#ae15f083570bcbf260dddf0bf6efbdd6e

When I last checked Android, it was limited to OpenGL ES. Not sure if I would classify an Android phone as embedded, but FLTK currently does not support Android. There are experimental versions that run on iOS and Android, but no details yet.

[Ian MacArthur]

On Wednesday, 16 August 2023 at 13:00:48 UTC+1 mc... wrote:

That is certainly good to know that all these scenarios worked for you, I think I may safely proceed with my current approach - plot stuff with OpenGL and not worry about anything.

Are you sure that in all these cases, the graphics were actually rendered in GPU? Or there is a possibility that fallback to CPU rendering kicked in?

That depends entirely on the target system implementation - and FLTK doesn't really "know" which will be used, it just makes the GL requests and the driver layer then implements them. Whether that then goes via GPU rendering or soft rendering depends on what the system driver supports.

On Linux systems this is typically done via the Mesa libs, which will implement this as "soft" or "hard" depending on what the system supports. For example, on a Raspberry Pi running X11 the GL rendering is likely to be "soft" because the available GLX rendering can't typically access the hardware render path - the same board *not* running X11 can access the "native" GLES path, so for some types of operations may be *a lot* quicker. (But there's also a Vulcan implementation for the Pi that is "hard", but using that is a whole different issue...)

In general, if you have built your code - and this is just as true on Windows or macOS as it is on Linux - and run it on different machines with different GPU/driver config., then the exact same application binary will use either "hard" or "soft" rendering depending entirely on what the target system supports. Any code you write just accesses the GL API, which is "the same" on all the targets.

 

I was also considering Cairo but I'm not sure if it attempts rendering in GPU.

In my experience, Cairo is never faster than GL - indeed on many systems it uses GL as a backend for its rendering.

I am aware that ES stands for embedded systems. I would appreciate if you could tell me what do you consider one and why FLTK needs special treatment for this use case.

Is it a lack of display server, perhaps? Surely not CPU architecture. I've work with both x86 lab instruments and ARM workstations.

What "embedded systems" means depends a lot on who you ask!

However, in general I'd say an "embedded system" will generally be more resource constrained than a regular system, may not be running one of the standard OS options (indeed may have no OS at all) and will probably be running a non-standard implementation of libc.

It is typically the OS option and the libc compatibility that limits whether or not FLTK code will run on an "embedded" system. Many modern IoT boards do have a full Linux/X11 stack on them, so FLTK can run on such a device, but many other embedded devices are far more limited...

[Greg Ercolano]

On 8/16/23 04:44, rageagainstthebath wrote:

I am aware that ES stands for embedded systems. I would appreciate if you could tell me what do you consider one and why FLTK needs special treatment for this use case.

Is it a lack of display server, perhaps? Surely not CPU architecture. I've work with both x86 lab instruments and ARM workstations.

    I'm guessing Matt meant things like phones, tablets, watches and other hardware
    dedicated to a specific purpose. So for sure FLTK hasn't been targeting iphones,
    and I think is only preliminary testing for android devices.

    I'm still old school myself in thinking of the term "embedded systems",
    which before phone/tablet computers were typically SBCs, or single board computers,
    used in industry to fit dedicated tasks, and in that case FLTK is actually a good fit
    because it's "light" on memory and executable size.

    So FLTK does fit well on devices like raspberry pis, beagle bone, and similar
    which are simply small computers designed to be flexible for use in embedded systems.

    But now with phones/tablets and other ultra-portable dedicated devices
    that have all kinds of strange requirements for GUIs and security, we really
    haven't been seriously targeting those; too many restrictions and hardware
    specifics devices, like interial sensors, detecting screen orientation, and
    touch screen stuff, which FLTK is only just investigating in recent development.

[rageagainstthebath]

Again thank you everyone for these wonderful explanations. I did not

realize most of that, and what I read here is both interesting and

comforting.

So I'm guessing OpenGL should work on almost anything, and I do even

recall reading somewhere about a translation layer from GL to GLES that

some systems may want to use. I'm about to only draw semi-transparent 

lines and points (and maybe text?), which I assume will be easy to translate 

to GLES if some internal OS mechanism chooses to do so.

Let's just agree embedded systems are those that do not meet current FLTK

requirements. ;)

From my perspective, embedded systems are single purpose machines with

fixed hardware configuration and custom low-level software. Something you 

can't run Doom on without substantial effort.

Tom

[Ian MacArthur]

I'm going off-topic a bit now but... 

On Thursday, 17 August 2023 at 08:39:44 UTC+1 Tom wrote:

Let's just agree embedded systems are those that do not meet current FLTK

requirements. ;)

Well, I have run FLTK on some *very* low resource embedded systems in the past (I had a port of fltk-1.1 to run on vxWorks, for example, that ran on very low spec hardware.)

And Georg Potthast runs a FLTK port on old DOS machines.

The "requirements" for FLTK, in terms of CPU resources etc.,  are not all that demanding, so if you are prepared to do the porting work, it can run in many places - but the effort involved in doing a port makes it impractical to maintain on the FLTK mainline, which only therefore targets the "main" OS targets.

 

From my perspective, embedded systems are single purpose machines with

fixed hardware configuration and custom low-level software. Something you 

can't run Doom on without substantial effort.

I'd guess that if it can run Doom, it can run FLTK, but the work implementing the port could be non-trivial (in either case!)

 

[Matthias Melcher]

Ian MacArthur schrieb am Donnerstag, 17. August 2023 um 11:30:24 UTC+2:

I'd guess that if it can run Doom, it can run FLTK, but the work implementing the port could be non-trivial (in either case!)

If it can run Doom and has a bit more RAM, it also can run FLTK . Maybe not the OpenGL part. There is code in various archives that implements 80% of a window manager including clipping and everything else needed to get a window system going with as little as RGB pixel data access. Besides screen access, we need a time base and any kind of pointer as an input source (mouse, touch, cursor keys with ok button, whatever). That's all.