enlightenment 17 evas gl engine

Message

user317 · Post by **user317** » Thu Jun 16, 2005 4:04 pm

how do i enable the gl engine in evas, i am getting about 10 times more fps in evas_gl_test over evas_software_test

MK · Post by MK » Thu Jun 16, 2005 5:22 pm

There is no easy way to change into the GL engine, you'll have to change it manually in the code. It's also very buggy, and really shouldn't be used unless you wanna play with it for fun, if not, stick with the software engine for now

genneth · Post by **genneth** » Thu Jun 16, 2005 5:23 pm

I believe that currently there is no global flag to set evas to use GL; each application that uses evas has to set it itself. Emerge examine, and whilst an app is running (for instance entice), run:

Code: Select all

$ examine entice

There should be some options, including something about rendering engines. Try changing it to 1.

vrln · Post by **vrln** » Thu Jun 16, 2005 5:42 pm

Don't waste your time - it doesn't work for the window manager itself. And the only way to enable it is to edit the source code before compiling.

user317 · Post by **user317** » Thu Jun 16, 2005 6:14 pm

what about on ibar and engage etc... I am just looking for something to play around with, i know opengl pretty well so i may be able to fix some of the bugs

. ill try examine once i get home, forgot to open up the ports on my new router.

pem · Post by **pem** » Mon Jun 20, 2005 7:56 pm

For the iBar, I guess it's too much intricated under the e17 wm (though, you can find the sources under the e17 repository apps/e/src/modules/ibar). For the engage module, it already supports the GL engine (engage -e gl).

So what about the WM itself. Having e17 in OpenGL would be a great improvement from my point of view. If you know this API a bit, it could be a good thing to help e17's team in improving the WM stability in this mode. From what I've seen here, vrln seems to have started something on this topic. Even if, according to the news, it seems a bit buggy, the results are promising ... Apple's Quartz could be worried about it

vrln · Post by **vrln** » Mon Jun 20, 2005 10:36 pm

pem wrote:For the iBar, I guess it's too much intricated under the e17 wm (though, you can find the sources under the e17 repository apps/e/src/modules/ibar). For the enage module, it already supports the GL engine (engage -e gl).

So what about the WM itself. Having e17 in OpenGL would be a great improvement from my point of view. If you know this API a bit, it could be a good thing to help e17's team in improving the WM stability in this mode. From what I've seen here, vrln seems to have started something on this topic. Even if, according to the news, it seems a bit buggy, the results are promising ... Apple's Quartz could be worried about it

Yup, my answer was before I found out that it actually might even work these days, on certain Nvidia cards at least. Forgot to edit my post here. I tried it and, well, it runs pretty well, but there is graphical corruption and it's not really usable. The Engage module does not support GL like that - if you launch it with a command, you'll launch the standalone version, which is not the one that should be used in E17. Instead the module uses the same rendering engine that the rest of the things on the canvas (background thing) use. The entire E17 does not run in GL mode, but the background (including modules etc) may or may not run, depending on your luck, drivers and card.

pem · Post by **pem** » Tue Jun 21, 2005 7:19 pm

BTW many thanks for your hints concerning using the WM in GL mode. It worked for me and I'm quite happy about it. I've been using for 2 days now whitout seeing any glitches. I guess that could be an option to set under an edb file.

vrln · Post by **vrln** » Sat Jul 09, 2005 11:40 am

pem wrote:BTW many thanks for your hints concerning using the WM in GL mode. It worked for me and I'm quite happy about it. I've been using for 2 days now whitout seeing any glitches. I guess that could be an option to set under an edb file.

What graphics card/drivers do you have? It works fairly well here too, but I'm having problems with image quality. Especially zooming icons look very unclean and low-res compared to software rendering.

It's neat that it works though, and I agree - there should be an easier way to enable it, even if it's highly likely that it's not going to work, but in the end I understand the reasoning why it's not selectable, as it would likely lead to all kinds of bugreports/"E17 hardlocked my system and I lost critical data" complains and so on.

Tried running those animated background by the way? It's pretty unreal to have the moving background running at 0-2% cpu :)

pem · Post by **pem** » Sat Jul 09, 2005 6:58 pm

@vrln
It's a GeForce4 440 Go 64M and I haven't tried the e17_bg_layered_sky.edj while being in OpenGL. As I've downloaded the latest CVS again, I've switched back to software mode

korda · Post by **korda** » Sun Jul 10, 2005 3:51 am

Running some parts of e17 in GL mode is a lot of fun. So far, only the init and container parts are usable in GL mode in e17, if you try the other ones (when you edit the e_config.c file as shown below) you'll see why.

Read http://get-e.org/Main/News_articles/47.html and http://edevelop.org/forum/viewtopic.php?t=1238 to learn how to edit the source and make the changes.

Engage runs very well in GL mode, when you turn on zooming and stretching you can see it fly. But I get very high CPU usage when I use engage with GL, about twice as much as when I run the standalone engage in GL mode, weird.

The start module shows some of the corruption you get, but if you resize it larger it looks good, maybe the GL zooming/resizing code somewhere in the EFL is a little iffy.

And the animated backgrounds, well. Impress your friends.