On Sat, 08 Nov 2003 12:17:42 +0100 Cristalle Azundris Sabon
<[EMAIL PROTECTED]> babbled:
> Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> writes:
> > it doesnt even obey the laws of "we will use more cpu but get higher
> > quality in return" (give and take). or vice-versa. you get extra
> > overhead with cpu, bus, ram AND a reduction in imaeg quality....
>
> "Don't eat candy, it's not good for you."
>
> In all my travels as the facts unravel, I found this to be true:
> People already know that, and they still want candy. : )
hehehe - good point.
> As far as *eye-candy* is concerned, I think we should be honoured
> and profoundly grateful people still come to *us* given how long we
> haven't delivered. True, we released a "greatest hits" rehash with
> an excellent extra track only last week, but the new album is taking
> forever. If on top of that, it's another concept album, only this
> time the theme isn't "it's your choice", but "we'll lecture you on
> what you *really* want", we have a real chance of antagonizing what
> little there is left of the fan-base. ; )
well for
1. DONT PUT IT IN EDJE.
2. DONT PUT It IN EVAS.
3. MAYBE it could be an option in ecore_evas
i still don't like it and am not keen on it because it looks just odd and wrong
in many circumstances and is horrible.
> > no aspect of this is positive.
>
> Quite apparently, people think it's fun. People enjoy using the
> program, and that's not positive?
>
> As for the mythical "quality loss", has anybody actually seen that?
> Not you, raster -- someone unbiased, please. : ) And I'm not talking
> about "I inferred it from the code." I'm talking "with my real-world
> transparency and shading settings, and my real-world backdrop, I
> actually *noticed* something with mine own two eyes, and it bothered
> me so much that I turned PT back off."
i dont use PT anymore as a result of all of these factors. run 16bpp or 8bpp -
hell have your bg pixmap set by a different program and rendering algorithm (ie
some gnome thing) ro e stuff and watch the 2 conflict and see dithering get
worse, or banding kick in... yuk!
> You see where this is going. If it were as bad as you make it up to be,
> people likely wouldn't be using it for long, anyway -- problem solved.
> If you don't like it, that's fine. But trying to "prove" that "nobody
> should like it" seems to achieve nothing? If there really is One True
> Taste, then why is e themable?
>
> "Last time I checked, e was about choice.
> When the official policy on that changes, kindly put it on the site."
at this point i'm MUCH more concerned about design. STOPPING the ugly hack that
E 0.13 and 0.16 have become. i am being ruthless in nipping problems in the bud
BEFORE they just bloom out to be a pile of ugly code that is such an abomination
to the eyes we end up with a rewrite again. PT just stands out like a sore
thumb. its just wrong (tm). i wish to god i had never supported it or helped it.
it'd one of the biggest regrets and mistakes i've made. do you think i am all
keen as a whistle to go and do just that again?
i repeat - it's place is NOT in edje. it's NOT in evas. maybe it's in ecore_evas
as a: ecore_evas_fake_transparency_set(ee, 1); call. then optional code in
there.
also - i DONT want to see normal E libs depending on stuff in proto/.
proto is for prototype stuff to play with. if things outside it start depending
on it - it needs to be formalized and moved out of proto, or the things
depending on proto/ stuff need to have their dependencies on that removed.
secondly - *IF* this is to be done, do it vaguely efficiently.
how:
1. listen to propertynotify events on root watching the root pixmap id property
- if it changes nuke current copy of pixmap in memory and start fetch process
again
2. fetch process should do the following:
2.1 on start of fetch create an evas_image object with pixel dimension the same
as the root pixmap
2.2 set the image to fill the bg of the canvas starting at 0,0 and being the
width and height of the canvas
2.3 set the image fill properties to account for the canvas's window position on
the screen (not as easy as it sounds! not if your canvas will be reparented
several levels down - and you cant always track movement!)
eg:
+---------------------------+
| root |
| +----------+ |
| | canvas | |
| | | |
| +----------+ |
| |
| |
+---------------------------+
in this example set the image fill origin to be -100, -50 (you get the idea) and
the fill width and height to be the size of the root pixmap. ALWAYS remember the
root pixmap can be TILED - it doesn't always "fill" the screen.
2.4 keep track of the visible "viewport" that the canvas has on the pixmap image
object - keep track of what pixels are used/visible, and ONLY fetch those (with
XGetImage/XshmGetImage) from the root pixmap the FIRST time you need them. use a
tile mechanism to break the pixmap into 16x16 or 32x32 or 8x8 or whatever tiles
and flag tiles as fetched or not fetched. when a new tile enters the visible
area, fetch it and mark it as "fetched". you you need to fetch multiple tiles
for a redraw then fetch them together as 1 Get, not multiple. merge tile regions
to be fetched.
3. dont SWALLOW fake transparent objects into edjes - it makes no sense! put
them in your canvas at layer -10000 or whatever and fill the canvas with them -
you're faking transparency - well put the thing where it should be then -
filling the canvas in the background trying to look like the desktop bg is
there.
> To wit, if you *don't* like PT, that's actually an incentive to put
> it somewhere in the libs (unless you aim to play the "no options for
> nobody" hardliner, thereby moving in on Havoc's GNOME2-act). That way,
> you can replace it with better tech once that becomes available, right
> there in the lib, fixing it for all programs that use it in one fell
> swoop, rather than having a dozen programs lie around that all implement
> PT in their own (and possibly more-broken-than-necessary) way.
PT doesn't fit - "shaped" is already supported and THATS what i'd planned to
extend when one day alpha comes to town for X. i've already accounted for that
and am waiting.
also it's not about no options - the options itself is so "out of place" in any
pipeline and design it stands out like a sore thumb. you're doing an ugly hack
to fake something that ends up half-arsed anyway. if REAL alpha was available
but ran at 1/4 the speed i'd still offer it - a tradeoff of speed vs. niceness.
but this isn't even a good tradeoff.
> Lastly, what alternatives are there? Apparently, Linux is the last
> party to still use PT -- correct me if I'm wrong, but didn't Apple
> use real transparency, only to drop it from the current interface
> because it's a usability nightmare? This is easily demonstrated in
no. it's still there - used and abused. people love it it seems. :)
> Win XP, as well -- you *can* create setups that don't suck, with
> pseudo- or real transparency, but it seems harder with RT, and most
> people I know turned on RT for half an hour as a tech demo (for the
> "wow" factor), and then turned it back off because it made text
> harder to read.
>
> thanks/regards,
> -A-
>
>
>
> --
> "E-16.6 beat Duke Nukem Forever. There's still hope for the world."
> http://www.osnews.com/comment.php?news_id=5062&offset=15&rows=24
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> enlightenment-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 [EMAIL PROTECTED]
Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
