Centralization of graphical awesomeness

[EdorFaus]

Bah, I write too slowly. Started when this mail arrived, didn't read the other 
responses yet...
----
This seems to be, in part, an issue of talking about different things... (see 
below)

On Tuesday 27 October 2009 10:01:58 DJDAS wrote:
> Carsten Haitzler (The Rasterman) wrote:
> > scrolling is different in qt. it is a simple blit. in efl it's a redraw.
> > efl is very much like GL. you get a lot of power and abilities with it,
> > but you do pay a price for it. unlike qt, efl's scrollers have smoothly
> > scaled item contents, backgrounds, translucency and everything. if you
> > make the theme SIMPLER with just solid rectangles, like qt - efl will
> > begin to be closer to the same speed. all that pretty stuff comes at a
> > cost. and people want their pretty. tone down the theme to bare
> > rectangles and text and it'll be faster. comparing qt and efl is apples
> > vs oranges. efl simply does a hell of a lot more in the graphics
> > department. and people are using that "hell of a lot more"
>
> AHAHAHAHAH.....Guy, please go home....
> I followed this thread and read too much bul***it but now it's very very
> interesting your position! So E it's a very
> optimized-full_of_fancy-magical-biggest window manager BUT all of his
> stuff works like Qt only if you don't use them! :D VERY FUNNY!

Your wording is far nastier than needed, but you're still sort of correct - E 
works *like Qt* only if you don't use those parts of E that Qt doesn't have 
(or doesn't use).

However, in this case, people are doing things with E that they aren't doing 
with Qt (possibly because Qt can't do those things?), leading to more work for 
E than for Qt, and do you *really* believe that it's possible to do more work 
in the same or less time, all other things being equal?

> Please stop spitting sh*t on the Glamo and the Freerunner, E is simply a
> pain-in-the-a** and nothing more.
> It never NEVER worked in an acceptable manner in EVERY my desktop system
> since 4 years (with nVidia graphics cards, not "GLAMO" or Freerunner),
> Compiz+XFCE are light-years way faster and optimized than that E's bunch
> of uncommented and "always-in.beta" (and not standards compliant) code...
> Please don't fool our brains and simply admit you are not able to work
> on embedded systems as on desktop (and personally I've got some doubts
> even on this).

You seem to be the one comparing desktop and embedded performance here...

And if Compiz+XFCE is so much better than E, why aren't you using that instead 
of E on the FR? Oh, right... Compiz doesn't work there, does it? Yet, E does.

> I can't accept to read something like "my code is highly optimized BUT
> as you have a shi**y device you cannot run on it unless you deactivate
> all its features"....go work in Micro$oft and write their "optimized"
> Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB
> RAM and 4 graphics card....

That's not what he seems to be saying to me. Seems more like "with this badly 
performing device, you can still use the features if you want, but don't 
expect it to be fast - if you want fast, don't use the fancy features".

Basically, there's a tradeoff between fancy features and speed.
Fancy features = more work, and more work = more time used.

The way I see it, if Qt was configured to do the same things as E is doing in 
the current GUI (assuming it's even capable of doing those things), it would 
be at least as slow as E is. Conversely, if E was configured to only do the 
things Qt is, it would do them as fast as Qt is.

Qt being fast thus being a result of it not using the fancy features, such as 
alpha blending with a background image (which E is doing).

> Be serious please...

Same to you. To me, you don't seem to be acting very seriously in this mail.

> > you have no idea how many optimisations they have. saying they need them
> > is like saying "linux needs virtual memory! it just needs it!". it HAS
> > it. in spades. read the code. you wont find routines for rendering faster
> > in most of the world. (when it comes to software). the other engines can
> > full offload to a subsystem (gl, xrender, etc. etc.) *IF* it is there.
> > WHAT e is doing is different to qt because thats how it is being used. if
> > you reduce what its doing to be the same as qt, you will find the speed
> > becomes similar. the reason qt looks faster is that it is simply doing
> > less.
>
> So E it's not as optimized ;) I prefer to "reduce" that "doing-thing"
> but have a responsive device instead of have to "read the code" to look
> how much is optimized to render like a Commodore 64

You're comparing apples to oranges - optimized code with optimized-for-the-
device GUI. The two are vastly different things, with different solutions.

Configuring which features to use is an issue of optimization - optimizing the 
GUI for the (limitations of the) device and the desires of the users.

An example of a GUI optimization that could be done here, is dropping the 
background image (the gradient) from the launcher, and using a solid color 
instead - if done properly, I think this would allow E to do blit scrolling, 
speeding that up quite a bit. (I might be wrong - I don't know the details.)
However, if people want the background image to stay, that isn't a solution...

What Rasterman is saying otoh (and I have no reason to doubt this), is that E 
has much better optimized *code* than Qt - which only means that, if they were 
doing the same things GUI wise, E would do them faster than Qt.

> I wish E to be fired ;)

Then use a distro that doesn't use it. Or reconfigure the one you do use to not 
use E on your device. Or, reconfigure E to do just the things you need it to, 
and see if it's still as bad as you think it is when it doesn't do all those 
extra things you don't want - if this ends up working well, others will 
probably thank you if you release your config so that others can use it too.

> I consider Glamo the worthiest thing Sean and his staff ever thought to
> add on the Freerunner but Qt with framebuffer are the proof that
> optimized and well written code is possible and even with Glamo some
> smooth and fancy GUI are possible...

Adding an accelerator was a good idea, yes. And I'm sure the Glamo looked good 
when they chose what chip to add. Unfortunately the Glamo turned out to not 
really be one, despite what they thought beforehand, due to its limitations...

> Nothing personal...

Same.

Bye,
Frode