This reply isn't really directed at you so much as directed at several
arguments I hear recurring from time to time..
* Valdis.Kletnieks@... (Valdis.Kletnieks@...) wrote:
> On Sun, 25 May 2003 11:31:47 EDT, Alan Schmitt <alan.schmitt@...> said:
> > other desktops ... So I'm wondering whether X may evolve to a "keep a
> > bitmap of all windows" model, or if it's too big a change and some other
> > system will replace it. Any thoughts ?
> You can get to the "keep all bitmaps' model fairly easily by simply enabling
> "backing store" and/or "save unders" on the server (although there's not
> *guarantee* that the server will actually do it, usually).
> A bigger problem is that it's actually harder than you think to get the
> semantics of this sort of thing right and get something usable. Two examples:
> 1) We currently have pseudo-transparent Eterms that you can park on your
> desktop and get the effect of text floating on the desktop. However, this
> does *NOT* extend to the general case - if you park several of them above
> each other in an overlapping fashion, they're not *really* transparent.
> This is probably a Good Thing - otherwise, you'd get an unreadable mess.
I have never agreed with this. If you apply some rule of opacity for
each window section back from the front a section is, eventually it is
only apparent there's more content behind it, but it's blurry or
otherwise not text-like enough that it's in the way.
> You get to deal with a lot of performance-messy stuff - for instance, if you
> are using anti-aliased text and have (say) 2 Eterms stacked, to do it right
> you need to take the bottom Eterm, composite its background and whatever is
> under it, apply the text anti-aliasing to THAT pixmap, then use that to
> composite to the upper Eterm's background and then apply anti-aliased text
> to THAT result. Painful enough?
> Now scroll the lower Eterm up a line. Have a nice day. ;)
I don't like this attitude, either. These are the sorts of problems
game developers have faced, which is why cards provide the functionality
required to do this fast. The software we use on our displays should be
expanding or otherwise moving towards supporting the features its users
want to see. That's the nature of a useful program, it continues to
provide what people want from it. Otherwise, you get things like code
forks, or dead projects. This is a problem I see with X development
lately, which is why the very public debacle that just occured within
the XF organization was probably a good thing for everyone, in the long
> 2) Usually, "transparency" is linked to "we want drop shadows", which is
> actually a different issue. Transparency, you have pixels depending on
> what's below them on the screen. Drop shadows, you have the issue that
> if your drop shadow is (say) 10 pixels wide and the window is transparent,
> then the actual value of a pixel 8 pixels below/outside the "upper" window is now
> dependent on the pixel value 2 pixels inside the window. That's bad enough,
> but now let's put another transparent window with its upper edge just 3
> pixels below the other upper window - so you have to take the first window,
> compute its shadow, put that onto the second window, and then bring that
> up through the other transparent window.
I also rarely hear people wanting drop shadows more than real
transparency as OSX implements it (or, as you say, Eterm pretends to
implement it). :)
> Now hit the keystroke that does a raise/lower in the stacking order. Have
> a nice day.. ;)
> OSX manages to deal with most of these corner cases because it's fairly
> fascist - it imposes policy on the apps. X could probably do it too, but
> it would have to be very careful to avoid breaking the "we don't do policy"
> mindset. And remember that "we don't do policy" is the only reason why
> Enlightenment can exist at all.....
Agreed, but we need improvements. Other graphics architectures
(Longhorn, OSX, etc) are beginning once again to take the cutting edge
away from projects like Enlightenment, and in part it's because the
project has had to invent its own additional layers (which have taken a
long time and have happened as the developers involved have all
transitioned to new jobs, etc) in order to catch up. Hence, ecore, evas,
edb. Some would argue that we could do without them, but really, we
shouldn't -- other graphics architectures have the same sorts of APIs.
In my opinion, the need for raster to write these APIs in part stems
from a culture surrounding X that we can't deem outdated features or
architecture as such and perform real innovation. Maybe I'm alone in
that view, but it is a view I have.