Hi,

I am working on a specefic GUI that need to be too fast and for this I have fpGUI or mse but in this project I need fast image and resizing and as I tested the fastest way for this kind of jobs OpenGL is the best so I made a project on it and everything is great and much much fast! So I want to ask is there any works on creating GUI with OpenGl that not be only for games or be for games but useful for specific applications and maybe using OS theme. I remember FireMonkey but in what we have Lazarus? I saw this but there isnt any specific answer
http://www.pascalgamedevelopment.com/showthread.php?32356-Looking-for-simple-GUI-library-framework If there isnt I can try to make simple one but I want to ask is it sane? Regards, Ara

Aradeonas wrote

I am working on a specefic GUI that need to be too fast

Why do you think there is anything faster than the standard GUI ?

Of course there are very special circumstances that would allow for some other GUI system to be faster.

- It could be a very restricted GUI. Here a TUI (Text based user interface) could be faster (drop the LCL and see FPC's TUI library)
- It could be a very complex threaded GUI. Theoretically you can do a multithreded application and have multiple threads each attach to it's own instance of the OS GUI API. With this, the GUI functions as well in the user program's library, as in the external Widget Set Library could work in parallel on multiple CPUs of an appropriate hardware. But this is not supported by Lazarus.

-Michael

Why do you think there is anything faster than the standard GUI ?

I need controls that has animations and images that need to be fast in?painting. I checked everything I know, the best result for graphical function is BGRABitmap but it is slow for high resolution painting so the best result I can get is with OpenGL and hardware and now I made it work.

LCL for standard jobs is very good but if you want animations or fast painting it use much CPU and flicker and ... . So the best thing I can guess is hardware acceleration for specific jobs but I want to ask if you know one or is it?sane?or not .

Regards, Ara

The normal GUI functions do use the hardware acceleration as they should. so no chance for a great improvement here.

The only way is multithreading to use multiple CPUs in parallel.

In fact we (company) do this using Delphi.

But Lazarus (or Delphi) can't do this on their own. So we did Flash animations (-> https://en.wikipedia.org/wiki/Flash_animation ) and have the flash player (dll) display them in appropriate rectangles placed in the normal GUI of the program.

A lot of work creating this (especially as supposedly will you need a realtime communication to feed your flash windows with new data), bu7t the result is excellent.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151130/f8193bcb/attachment.html>

The normal GUI functions do use the hardware acceleration as they should. so no chance for a great improvement here.

Where can I read more about this?

So according to what you say problem may be using one handle per control so resizing will make flickering. Is there anyway to disable this like fpGUI or mse? Regards, Ara

Aradeonas wrote

Where can I read more about this?

The LCL uses the Windows API or a Linux Widget Set API, and both are highly optimized to use the hardware Graphic processor for all provided functions (such as rendering Text and standard objects).

If you need advanced high speed graphical Features (such as zoom/pan/move/3D views of objects residing in the memory of the GPU), you need to use other libraries (not being called "GUI") such as Open GL, SDL or - less "basic" - Flash)

So according to what you say problem may be using one handle per control so resizing will make flickering. Is there anyway to disable this like fpGUI or mse?

Flickering and speed are completely different issues. Usually flickering is suppressed by triple buffering, reducing the speed by needing more CPU time.

-Michael

MSEgui has an experimental OpenGL backend. OpenGL is not well-suited to support 2D GUIs IMO. Because of the many different versions and implementations, all with different extensions, limitations and bugs, working with OpenGL is a difficult task.
MSEgui uses hardware acceleration if available. A framework for animations with a central frame tick and the like is planned, although performance of simple hardware accelerated canvas drawing is not bad, see for example: http://mseide-msegui.sourceforge.net/pics/blend.mpeg http://mseide-msegui.sourceforge.net/pics/blend1.png http://mseide-msegui.sourceforge.net/pics/blend2.png http://mseide-msegui.sourceforge.net/pics/blend3.png The project is here:
https://gitlab.com/mseuniverse/mseuniverse/tree/master/samples/widgets/blendpos (needs MSEide+MSEgui git master version).

The code:
"
procedure tmainfo.childmouseeventexe(const sender: twidget;
                                   var ainfo: mouseeventinfoty);
begin
 image.face.image.center:=
                TranslateWidgetToPaintPoint(ainfo.pos,sender,image);
end;
"
The whole rest are design time property settings only.

I remember FireMonkey but in what we have Lazarus?

AFAIK FireMonkey has no good performance.

Martin

If there isnt I can try to make simple one but I want to ask is it sane? Regards, Ara

Yes it is.
Looking forward to it.

R.

P.S.: Don't give too much on Michaels theorizing.

If you need advanced high speed graphical Features

<snip>

... or - less "basic" - Flash)

Made my day.

R.

Michael Schnell wrote

bu7t the result is excellent.

I don't have Flash player installed. IMO it's bad practice to force your users to install any third-party software.

Ondrej

Thanks Michael,Martin,Reimar and Ondrej. As you said martin it is not easy to use but give you very good performance.I tested it with BGRABitmap OpenGL and it can be very good. But it can have many problems like making text box or memo or whatever. I know there are GUI components with OpenGL even with Pascal but I couldnt test anyone and want to know is there any one here test them or have experience in this field or not. Martin is mse support transparent text box or these component with OpenGL? As I remember you said that mse use no handle per control so what mse do for text component or lists?

Regards, Ara

OpenGL is not well-suited to support 2D GUIs IMO.

Depends a lot on what kind of GUI you need.
Blenders GUI for example gains a lot IMHO by being implemented in OpenGL but users of blender are also more likely to have good graphics cards.

Because of the many different versions and implementations, all with different extensions, limitations and bugs, working with OpenGL is a difficult task.

That's true but something like 2.0 or 3.2 can most likely nowadays be reasonably targeted. If you go 1.2 it should work everywhere. On phones you can offen use the current version as people upgrade their phones often. Often more problematic are different driver versions and their bugs. If you want to really handle all versions it gets really cumbersome as you have to implement different render paths as the most optimal path differs greatly between OpenGL (major) versions. Hopefully things get better with Vulkan.

R.

Reimar Grabowski wrote

P.S.: Don't give too much on Michaels theorizing. --

Ara did not state what exactly the problem is he is facing.

And it is not theory that with modern systems multiple CPUs are common and most "GUI" libraries don't support multiple threads.

If what he intends to do needs a lot of calculations (besides what can be moved to the GPU) obviously distributing the work on multiple processors by utilizing multiple threads will help.

Been there, did it.

-Michael

Aradeonas wrote

Martin is mse support transparent text box or these component with OpenGL?

In the experimental MSEgui OpenGL backend? Yes, transparent text is supported. But it is experimental and the performance is not very good.

As I remember you said that mse use no handle per control so what mse do for text component or lists?

MSEgui sends graphics primitives to xlib or xrender on Linux and FreeBSD or to gdi32 or gdi+ on Windows.

Martin

Ondrej Pokorny wrote

I don't have Flash player installed. IMO it's bad practice to force your users to install any third-party software.

But Open GL ?!?!?!

-Michael

That's true but something like 2.0 or 3.2 can most likely nowadays be reasonably targeted. If you go 1.2 it should work everywhere.

On phones you can offen use the current version as people upgrade their phones often. Often more problematic are different driver versions and their bugs. If you want to really handle all versions it gets really cumbersome as you have to implement different render paths as the most optimal path differs greatly between OpenGL (major) versions. Hopefully things get better with Vulkan.

But as I read about this a problem is for example in Android phones their support OpenGl ES and taht is diffent to OpenGL like does have glBegin glEnd and it can be kind of problem? It seems you have experience about this?What you think?

Regards, Ara

On 11/30/2015 01:35 PM, Reimar Grabowski wrote: Ara did not state what exactly the problem is he is facing.

had used OpenGL to do the GUI for a project (as he had found by testing that this was the fastest solution). Now he wanted to know if it is viable to create a simple OpenGL GUI library or if there is anybody already working on one. No need for your well known "multithreading chatter".

R.

He had used OpenGL to do the GUI for a project (as he had found by testing that this was the fastest solution).

Exactly. I dont know why but I am fascinated about fast GUIs. I am not a professional game developer but for my projects sometimes I need animations and image processing and Im tired of making a graphical component or a especial painter for a case and want to know is there any work available or it is a sane way to make all of my components from OpenGl or something like this and even used OS theme for my view like getting windows 8 draw for a button but make it as a texture and give it to my imaginary button component. As I said I saw this in Firemonkey .It even make DBGrid 3D! I dont need 3D component but I need fast accelerated OpenGL or something like this for my custom GUI. Regards, Ara

Reimar Grabowski wrote

No need for your well known "multithreading chatter".

Just trying to help...

-Michael

Just trying to help...

Thank you very much Michael and I want to know more about this system.Maybe It not used in this case but be used for my current UI system or next one.

Regards, Ara

But as I read about this a problem is for example in Android phones their support OpenGl ES and taht is diffent to OpenGL like does have glBegin glEnd and it can be kind of problem? It seems you have experience about this?What you think?

First of, everything concerning glBegin and friends is ancient stuff, don't touch them. Don't touch glMatrix* or anything like that, too. Do it on your own (even in JS if you use WebGL). In short: Do the matrix math on the CPU, use the most optimal vertex submission mechanism supported by the targeted version (vertex arrays, VBOs, etc.) and use shaders. Second, every platform has its own flavor of OpenGL: OpenGL for the Desktop, OpenGL ES on mobile and WebGL for the browser. All are similar and yet quite different. All have their own versions and the associated problems. Use OpenGL only if you need its features and then pick your platform and don't try to handle them all in one software. OpenGL is not easy to handle and you really have to dive in deep to make the most of it. You can do a lot of stuff really fast but the API is very old and it shows more and more. You have very little direct control of your graphics hardware and moving data to/from the card is cumbersome. Personally I am waiting for the successor of OpenGL (Vulkan) which does away with the multiple platform versions (Normal, Web, ES), unifies them and is stated to give you much more control of the hardware. I am sure things are not getting much easier in the high speed graphics department but a lot more organized and hopefully better to maintain.

R.

First of, everything concerning glBegin and friends is ancient stuff, don't touch them.

Don't touch glMatrix* or anything like that, too. Do it on your own (even in JS if you use WebGL). In short: Do the matrix math on the CPU, use the most optimal vertex submission mechanism supported by the targeted version (vertex arrays, VBOs, etc.) and use shaders. Second, every platform has its own flavor of OpenGL: OpenGL for the Desktop, OpenGL ES on mobile and WebGL for the browser. All are similar and yet quite different. All have their own versions and the associated problems. Use OpenGL only if you need its features and then pick your platform and don't try to handle them all in one software. OpenGL is not easy to handle and you really have to dive in deep to make the most of it. You can do a lot of stuff really fast but the API is very old and it shows more and more. You have very little direct control of your graphics hardware and moving data to/from the card is cumbersome. Personally I am waiting for the successor of OpenGL (Vulkan) which does away with the multiple platform versions (Normal, Web, ES), unifies them and is stated to give you much more control of the hardware. I am sure things are not getting much easier in the high speed graphics department but a lot more organized and hopefully better to maintain.

R.

Very interesting point about OpenGL and Vulkan.Thanks. By the way do you know any implementation of OpenGL or Vulkan for GUI in pascal for my recent research?

Regards, Ara

Aradeonas wrote

If there isnt I can try to make simple one but I want to ask is it sane?

Don't kid yourself....making a functional GUI toolkit is no simple or quick task. Martin and I would know. :-)

It seems what you are after is FireMonkey. Maybe purchase a copy of Delphi that includes FireMonkey and see if you can port it back to FPC - then maybe sell your solution back to Embarcadero. ;-) Then again, Embarcadero's licensing probably forbids that.

As a FireMonkey alternative, take a look at CodeTyphon's Orca and Orca3D packages. Then again, as far as I can see, those are illegal copies of FireMonkey's precursor - VGScene. CodeTyphon simply "rebranded" it as Orca and hidden between the many packages included with CodeTyphon. [if I am wrong, I welcome anybody to correct me]
I don't condone such actions, but there you go.

Regards,
- Graeme -

Martin Schreiber wrote

OpenGL is not well-suited to support 2D GUIs IMO. Because of the many different versions and implementations, all with different extensions, limitations and bugs, working with OpenGL is a difficult task.

+1
Somebody previously tried to make a OpenGL backend for fpGUI too. They quickly noted that the different versions of OpenGL, OpenGL ES etc etc are a real pain. I'm not saying it can't be done, I'm just saying it is a pain.

Regards,
- Graeme -

My public PGP key: http://tinyurl.com/graeme-pgp

Aradeonas wrote

Thank you very much Michael and I want to know more about this system.Maybe It not used in this case but be used for my current UI system or next one.

In fact there is no "system", just some obvious consideration.

As I stated we used Flash to create many small animated windows within a GUI, and are happy with this, but this can't be considered a GUI system.

Regarding multiple threads (and with this CPUs) driving a rather standard GUI in parallel, I believe that something like this can be done using standard GUI libraries (like KDE or GTK, or Windows). If such a library gets an initialization call from a Process, it can detect the process ID and the Thread ID. it needs to allocate some memory for the future work. When we want to use a single GUI per Process and access it with multiple Threads (which might be forbidden) there would be a single base of resources per process (and if allowed, the library needs to synchronize multiple threads appropriately) . If we want to use multiple GUIs per Process (one per Thread) these resources would need to be allocated on a per thread base.

I can't believe that the API makers did not consider the two obvious cases (even though a process with multiple independent GUIs is not a very common task to do, but obviously the parallel work of multiple CPUs might speed up things.)

Obviously, if you want non standard speed, you need to consider non standard complexity.

-Michael

Thanks Graeme. Im not going to make GUI toolkit,Just controls that I need.fpGUI and mse are full and functional kits but I want a simple and with special target very fast GUI.

Regards, Ara

Obviously, if you want non standard speed, you need to consider non

standard complexity.

Yes I think like this.As I guess your products are not for end user client so you could use flash without any problem and in my case I want it for some special case and clients so making an special GUI on OpenGL can be an answer because as I said in this GUI there is many image processing and the best I know is OpenGL. But I be happy to know any other solution or a GUI made already.

Regards, Ara

Very interesting point about OpenGL and Vulkan.Thanks. By the way do you know any implementation of OpenGL or Vulkan for GUI in pascal for my recent research?

Unfortunately not.

R.

In fact they are for end users, but the software is just part of a huge system and installing the flash player is really a relatively small issue. :-)

-Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151130/dbf654d1/attachment.html>

Is this something that can be of use for you ?
http://tulip-ui.azurewebsites.net/

CodeTyphon has some GUI (HUD) OpenGL example !
Example Projects, AsphyreSphinx, BasicGUI.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151130/9583142d/attachment.html>

AsphyreSphinx is now Pascal eXtended Library.
The Author left Emba and reopend the Projekt.
In some Forumpost he mentioned to do some work on tulip-ui too.

http://www.afterwarp.net/
http://forum.lazarus.freepascal.org/index.php?topic=29852.0

AsphyreSphinx is now Pascal eXtended Library.
The Author left Emba and reopend the Projekt.
In some Forumpost he mentioned to do some work on tulip-ui too.

http://www.afterwarp.net/
http://forum.lazarus.freepascal.org/index.php?topic=29852.0

Doesn't Cairo have a hardware acceleration backend? Then again, you'd have to have a cairo dependency.

- Dennis Fehr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151201/fb7e224d/attachment.html>

http://tulip-ui.azurewebsites.net/

Not the UI controls but the engine maybe.

AsphyreSphinx is now Pascal eXtended Library.

I read about it but I didnt test it,any one here has experince with it?

Doesn't Cairo have a hardware acceleration backend? Then again, you'd have to have a cairo dependency.

It seems it use cario is for Linux(I dont know it),can it used in Windows with fast accelerated graphical functions?

Regards, Ara

Den wrote

Doesn't Cairo have a hardware acceleration backend?

Is there *any* GUI based widget type in Lazarus that does not attach to a backend that in the end triggers the primitives to be handed via an OS API and with that sent a graphic-hardware driver and with that has them rendered by a GPU if available ?

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151202/84db9fd1/attachment-0001.html>

Michael Schnell wrote

Is there *any* GUI based widget type in Lazarus that does not attach to a backend that in the end triggers the primitives to be handed via an OS API

Explain "graphic primitives"? Do you mean API for things like Elipse drawing, Line drawing, Text output etc.

If so, then yes, fpGUI is such a widgetset. fpGUI's "develop" branch is switching over to using AggPas for *all* those graphics functionality. Line drawing, text rendering, anti-aliasing, alpha blending, vector graphics etc. This is turn makes fpGUI very portable with little effort, because now only top-level windows handling, clipboard and DND functionality talks to the OS (those are unavoidable), the rest is all handled in fpGUI and AggPas. In turn the LCL-fpGUI widgetset would use that too as far as I understand.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Explain "graphic primitives"? Do you mean API for things like Elipse drawing, Line drawing, Text output etc.

Exactly.

Especially text rendering is a very time consuming task that is used a lot when rendering the GUI of a usual desktop application.

It's really great to have this, allowing for an extremely portable hardware and OS independent development tool.

-Michael

Michael Schnell wrote

Especially text rendering is a very time consuming task that is used a lot when rendering the GUI of a usual desktop application.

For desktop apps, I haven't seen a noticeable slow down in text rendering, using fpGUI's develop branch. I tested with fpGUI's nanoedit (basic text editor) and maximus ide projects, loading text files and then scrolling with the mouse or keyboard.

General desktop apps are pretty static, so things are less noticeable by the human eye. Animation effects (like seen on Android and iOS) is another matter - they benefit from the GPU a lot.

Regards,
- Graeme -

Animation effects (like seen on Android and iOS) is

another matter - they benefit from the GPU a lot. And this is Im looking to.

Regards, Ara