Those features were never removed from FVWM or Enlightenment - just you chose to use different WM's that choose to assume you, as a user, are stupid and don't need or want features. You will be confused by since completely incomprihensible features and thus should never have access to them lest you explode from confusion!:)
Just go back to using your favorite WM's and they will keep doing what they always did.:)
Where does it say you need to be a student? The closest I see is "no corporate entries" - ie a company cannot submit. Doesn't stop someone working from doing one in their own time and submitting as an induvidual?
PNG BETTER for high-traffic? yeah right (the short version). if you are high-traffic that means lots of images downloaded - that means lots of bandwidth. you want to reduce bandwidth - thus reduce image file sizes (or reduce the size and/or number of images on a site). jpeg uses lossy compression that means it will LOSe image content/data in return for compression. in most cases if the image is "realistic" (a photo) and not purely hand-drawn, jpeg produces much smaller file sizes at mostly indistinguishable quality (given a good quality setting) for most people, or acceptible degredation in return for MASSIVE savings in file size. in fact it can be 1/5th the size or even 1/10th the size of the same PNG for the same content and visually be "as good". with jpeg you do not get an alpha channel so it's not useful for cases where you want that, and it's also not useful if the quality loss is not acceptable - but in ALL other cases, jpeg will get you much reduced bandwidth requirements compared to png - the vast majority of the time. i suggest doing some reading up on image compression techniques and image file codecs.
aaah this explains the gartuitously slow code on todays machines. people thinking snprintf is better than strcpy/strcat.
snprintf method takes: 0.571 sec for 1,000,000 iterations, strcpy etc. 0.124 sec. you have to think that every time you do something you choose a method 4+ times slower that no wonder today's software is not appreciably faster on machines 100+ times faster that they were 10 years ago.
code for the test: #include #include
int main(int argc, char **argv) {
int i;
char buf[1024];
char *s1 = "/path/to/whatever/here/to/test";
char *s2 = "a_file_name_goes_here.blah";
for (i = 0; i 1000000; i++)
{ #if 0
snprintf(buf, sizeof(buf), "%s/%s", s1, s2); #else
strcpy(buf, s1);
strcat(buf, "/");
strcat(buf, s2); #endif
} }
what i need is something like... ooh... a job to DO enlightenment instead of doing it on evenings and weekends. trust me - a manager would be able to do nothing here - he has no resources to work this. they have all gone usefully into building what is the back-end of e17 (itsw rendering, theme, core event layer etc.) and it's paying off now in leaps and bounds.
what you may not realise is - my day job has nothing to do with x, graphics, e, etc. it's rather mundane, BUT i get to see the world and experience life:)
damn my stomach hurts now. (BTW - dont have anything against Havoc and Seth at all - maybe they should just pop an eye over E one day - it might give them ideas... help them out):)
In what spare time? We already work FULLTIME on E stuff - and fulltime means evenings and weekends. NONE of us get paid to do this fuloltime. If we had that time I'd be helping tomorrow as getting Xrender to not suck (it's software fallbacks be sane in terms of speed) is in our best interests - as well as everyone elses, but until we have that opportunity, we have already written all our own software rendering and it works for us.:( Someone come up with an offer to let us work on this fulltime - then please speak up and contact us. We put our code were out mouths are - always have, always will.
It's BSD - I just think people don't care. I don't care much myself - except everyone runing around as if Cairo, using opengl for 2d rendering etc. is all new stuff and freedesktop.org are the pioneers in doing this on linux etc. etc. etc.
I can say why - it's not "a gnome" or "kde" project - thus it's mostly ignored. As I said - I don't really care much - but I would like to point out - we have implemented, and have runing most of what Seth talks about. It's working, and working at a good speed WITHOUT the need for hardware accel. We CAN use Hardware accel - but see above.
If people want to SEE it working already - check E17 stuff out of CVS - watch the avi's, look at the screenshots, browse the code etc. etc. etc.
OK - I see another E thread... Time to inject some fact in here (some of this thread so far is fact, some is over-exuberance, some is patently false).
OK - First. E17 has had all the stuff seth is alking about FOR Cairo, GTK+, Qt - ALREADY DONE. Years ago. Been there. Done that. Been wating for 5 years for XRender to stop sucking. Sorry guys. It does suck (in general). Do some benchmarks. We have had OpenGL acclerated rendering for 2D for years. Evas has enabled that long ago. We choose NOT to use it due to 1. most users NOT having accelerated cards capable of drawing well enough for 2D use (all you i8xx users? s3 savage? via unichrome? just ask all wonders of modern ati cards how great their ati closed drivers are in stability? etc.), and 2. driver stability is so bad, using OpenGL is like asking for an instant system freeze. Linux users like to tout how stable it is - give me 5 minutes on any linux machine with nvidia or ati cards... freeze. It has improved over the years - definitely, but it still is unstable - to the point where we support it but don't trust it to enable it by default. All the playing Owen, Seth etc. are doing and talking about, we have done "in principle" years ago - but no one was interested much. The code has been available for years in CVS. Just check the logs.
We have all the fancy "Indiana Jones" effects done NOW. We have the effects engine done (macro-media flash like system we call Edje, specifically designed to do layout, animation and interaction and act as a slave to a widget set/app). We have an accleratable, re-targetable canvas (Evas) that supports Software X rendering (the highest quality and most stable one), OpenGL (very fast if you have dirvers, but lower quality due to OpenGL resampling for scaling down - mipmaps dont fly for 2D), DirectFB, Linux Framebuffer, Qtopia, System Memory, and yes - we have a CAIRO engine. They are all selectable at runtime by the app and compile time too, so none are REQUIREMENTS, just options. Now just for your info - on every machine I have (1 laptop, 3 desktops - nvidia, ati, i865 and g400 gfx cards) Evas's Software X engine is in the order of 20-40 TIMES faster than Cairo. I can go into details as to WHY and the Cairo devs know and agree as to why (we discussed this - thats why i wrote the engine hooks as a test case) - but first before everyone runs around half-cocked, get some facts on the viability of these things. Evas can pull the same tricks Cairo does via glitz - use OpenGL. We have been doing this for years. We consider it too unstable for production use at all. Punting everything via OpenGL is not a walk in the palk, and has its drawbacks - if you do, WITHOUT a good software fallback system, you have just left every user of a non nvidia card in the stone-age. We do not believe that is a viable thing. Sure - SUPPORT modern cards and get acceleration from them, but don't alienate those with older cards and older systems. At this stage the only rendering engine I have seen to date that can provide the same visuals AND at an acceptible speed is Evas, and still take advantage of modern GPU's via any API made available.
We are doing most of what Seth "dreams of" already. Have been doing so for years. And we have more on our TODO list. UNLIKE relying on CAIRO etc. we can run fast on LEGACY systems WITHOUT special X extensions, and run usably fast (see testimonials on people on 400Mhz or below boxes). We even target embedded devices with our engines (50-200Mzh ARM CPU's). We have an abstracted engine system so we can slide in any rendering technology when it becomes usable. We are WAITING for XRender to become usable (en masse - not just in 1 monolithic xserver for 1 subset of chipsets). We happily continue with the rest of our design and code and dreams being able to bide our time and wait because we have a usable software layer already. We don't RELY on NEEDING a hardware layer. We CAN use it. We CHOOSE not to. See above as to why.
Re:Enlightenment's still the best eye candy WM aro
on
E17 Available From CVS
·
· Score: 1
whatevere.
the day you contribute to opensource - let me know. put up or shut up.
Re:Let's get some things straight here
on
E17 Available From CVS
·
· Score: 5, Informative
1. the xserver was severely slowed down thanks to xvidcap hammering x to capture pixels (e17 was runing inside xnest which was running inside x, and xnest basicaly nukes extensions so all the speedups you get on a real x are gone and the extra indirections really hurt). 2 it's encoding a video realtime while e17 running and xvidcap is hammering x to grab pixels, 3. no it wont be faster not animating as the window pops up instantly and reacts instantly - you just get to see the animation. i like it and its insanely smooth "on a real display" the video is just an indication. get it, install it, run it yourself to see what i mean. the video does not do it justice. sure - you can remove the animation - no code changes needed. it's part of the theme. themes can animate and transition as they like. also the "it uses opengl" comments are wrong. it *CAN* use opengl *IF* it inits using opengl to render. we have a perfectly fast software rendering engine that beats the pants off most things around. all the exmaples you see all use the software renderer. no opengl or hardware help. in fact our preferred renderer is software. its 1. more reliable (stability) than opengl, 2. higher quality than opengl or xrender, and 3. in most usage scenarios much faster and smoother than opengl or xrender - even IF opengl is hardware accelerated (due to lock contention, DRI etc).
It had pagers and virtual desktops in multiple incarnations and ways. I will admit I have not read ALL of thepatent claim - just about half of it. I understand legalese and some of the claims in the patent are prior art. Why? I wrote the code myself to do just that in enlightenment. But this is some of them. It would be easy to prove prior art - just give me a day in court:)
Others I haven't actually seen before, though I would say they do fall under "obvious to someone skilled in the art". Well they are obvious to me - several were always on my "i'd love to do that" list and i had on the cards, but simply X didnt provide the horsepower or api to do it, so it was left out for practical reasons. They are simple effects like "take a snapshot of your screen and then just scale it up and down as an animation transition". It's really BASIC stuff done repeatedly in many ways. E has done this for pagers, well parts of them. It did it with induvidual windows - it'd scale and zoom in on a window as you moused over it (within the pager) so you could better make out the thumbnail contents.
Now what I don't know is if you can deny a claim when sufficient parts of it art prior art and most of the rest is obvious to someone skilled in the art.
IMHO the USPTO should try and keep some experts in fields on retainer - at the very least start a search on existing experts who work and develop/create within those fields. if they get an application that falls within that field, fire off some e-mails and ask the people who are the real experts for known prior art or obvious. The USPTO calls the final shots, but at least they get some good informed responses. If they wanted guaranteed response times they could pay them on retainer too. Since it is a filed patent application and public knowledge, there is no harm in making these questions public BEFORE it gets granted and then has to be tested in court.
well just a correcttion. evas has several rendering engines:
1. software (it uses your cpu and does all the work in the program, not in X. it will use mmx if you have it - its fast and usable and is the default)
2. x11 (xaa - uses normal x calls - all of which go through xaa. it uses normal x lines, polygons, rectanlges, pixmaps etc.)
3. image (again software - client side - but renders to local client side memory too as a final output - handy for being able to save the canavs to a file such as a png or jpg, or being able to do other thngs with it)
4. render (uses xrender extension - so far i only have stubs. i have some of it going locally here - but not enough to bother committing to cvs)
5. hardware opengl (uses opengl for the back end rendering - you take it from there)
the application gets to ask evas for the rendering engine it wants to use. if its not available (no opengl on the display system or it wasn't compiled in, or the render extension is missing etc.) it will always fall back to software rendering.
well actually x doesnt do alpha channels for windows - the window you see there just as "no background" for isn't background which means if you map the window it inherits the current framebuffer contents. you are only seeing x doing alpha compositing.. and no - keith hasn't thought of everything. he's thought of a fair bit.. but not everything. currently image transforms are unimplimented. there isn't even an api call for them. i'm tryng to get at last this fixed:)
the fact that evas has is "canvas" is nothing new. it's an ancient idea. the fact that i did start it off simple and dind't go completely bezerk with abilities and features (display postscript, display pdf) - just kept the core and basics, meant that i could actually finish it in time to use it for writing the app i needed it for: e 0.17 AND it menat i could also accelerate it via multiple back end rendering paths. it's quiteodd too the apeolpe assume it is ONLY opengl - in fact i woudl not suggest using the gl backed rendering engine on anything but an nvidia driver because so far no driver i have found comes even clsoe to being stable enough or complete enough. but nvidia is about the closest. my own software rendering (imlib2 does that for evas) which is quite fast is what i normally use for evas - so you don't NEED hardware. you can use normal X11 pixmaps and X primitives as a rendering back end for evas too. this keeps it simple - but still makes it able to be extended easily, and has allowed me to make it work and work well in a relatively short period of time with a relatively small amount of resources.
that is what the power is.. and it can be easily extended. new object types can be added - new things like having clipping paths could be done, extra object attributes can eb added that affect their display.. but the more complex the feature the harder it is to support in the back end rendering... and the less likely it is to be able to be hardware accelerated and instead have to be done more slowly in software - even the software optimizations are lezz liekly to be effective the more complex it is. thus i choose to only impliment what i really need - and that can go a surprisingly long way:) the end result is a canvas that is fast.. hardware accelerated or not, that does its primitives well and does the job i need... and can be improved in time with no effect on the programs using it other than positive ones (new features... or faster & better quality rendering etc.)
evas solves the problem in an elegant way... and rememebr it isn't the same as dps/dpdf - its a canvas. that is a different concept.
i also know a bit more about apples display technology than you think - it defintiely is pretty - and yes... i'm not going to comment much in detail on it as i dont, imho, think i know enough details to make a very concise sumamry of it and get it right 100%. but i know enough to know what they are doing (approximately) and why etc.
evas is a different technology - it is much closer to the java canvas, tk canavs, gnome or qt canvases. it can be extended and wrapped and made more pwoerful with layers ontop that use it as an optimized rendering system... and that is incendentally one of the side projects happening right now:)
anyway.. just thought i'd comment a bit - don't want to flame - just want to fill in the gaps ininformation that wasn't provided for you before:)
..." I do like the flexibility of E and the fact that it can be quite efficicient when you want it to be, but that pager is the biggest CPU hog ever. Its pretty, but I don't see enough functionality to justify the resources it demands, even on a reasonably fast machine. "
turn snapshottign off - you'll find them as fast as any other pager:) as has been noted almost everyhting is E is turn-off-able - if the feature is a bit too much for your box.. it can be turned off - for my mahcines it was barely noticeable that it was turned on..:) just a remiinder that E is configurable.. if a feature "offends" you - visually, cpu-wise etc.. u can turn it off:)
BTW - dunac was noting the memeory footprint of the code i think in his VM comment - so even if the code is bigger - unused code pages are never paged in form disk.. thus they may appera to take ram in PS and TOP - but infact they don't = if that page of code is not executed:)
E was around LONG before GNOME was. E started back in lat '96 and actually had working code back then.
E had pagers long before there was a gnome spec to do them - yes - they dissapeared for a while because that bit of code was being rewroked. The end result was they came back and people loved them.
This is not an ego question - I don't knwo where you got that idea. E was never desiigned to be minimalistic for gnome - I walways had a vision of having a desktop of my very own that woudl feel like my good old amiga workbench but on steroids - why shoudl I stop just because gnome appears? E still manages apps - any wm does that.
E was used to ship with GNOME because no other WM was fast enought to come aroudn and support gnome WM hints - E wasn't designed to be minimalistic - I didn gnome work because I was paid to do it - not voluntarily because I liked it - I was hired by Red Hat and basically turned up and found out "guess what - your'e working on gnome!" - which was infact the kind of project i'd been heading towards for a while with E - how yould you liek someone to destory youre hopes and dreams and ideas by turnign your project you've been working on for ages and been dreaming up for years into a spare tyre? some of us beleive it or not are more resiliant than that - we dont give up. e just supported gnome - it was never gnome's wm. if you had any idea you'll notice that i spent months ont he gnome list statig that gnome needed their own wm - but no-one listened or agreed - until it was too late and they realised they needed one. i think it may infatc be more arrogance on gnome's part thinking they can work with any wm withotu any formm of extra communication happening because they dont realise the scope of freedom icccm gives a wm. to get gauarnteed behavior they need their own wm - otherwise there is no guarantee.
e is getting a file manager primarily because i dont like gmc or kfm - and i dont like nautilus. they all feel so windows explorer-like. many people might liek that - but i dont. i'm not here to advocate opensoruce or produce "the linux desktop" or make gnome better or such - gnome is doign a more than admirable job in developing an application development layer - it's execllent work - so is kde. i think they shoudl both continue on that goal and make it better. but E is not gnome - it's not part of gnome - it never was. opensource gives anyone the freedome to come up with their own solution - and that's what i'm doing - that's what gnome is doign and that's what kde is doing - thats' what window maker is doing... do you want to deny people their freedom of expression?
think about it a bit more. maybe you've never had somehting you've created your'e proud of - then you just don't know the feeling. it's like haveing a child and watching them grow up. E was never meant for gnome - our goals had way too much overlap. i wasnt goign to relent on my goals and ideas and dreams just bcause gnome needed a wm.
All I have to say is - congratulatiosn and well done. Keep workign oon RXO - the more competition, the better - it means i wont have time to get lazy. i'm goign to check this out and have a look.
i wish people would be more positive and offer encouragement not disparagement just because someone has a project they want to work on and it isnt what you're wishing was "the thing". let people have their projects - often they have a good reason they started it.. and sometimes they are so far into it that they aren't just goign to give up because someone else has a similar project...
Well done ROX - keep it up... Glad to see more stuff around.
-> Hey, how does this work out? I was under the -> impression that the WM just handles the border, -> resizing, etc. of Windows in X. If -> that's the case, then how does 3DWM show a -> window from a different angle? Wouldn't it be -> more like a replacement for the X -> server?
yup - what you see here is NOT a Window Manager the ONLy way to accomplish this is for the "so called wm" to be a proxy Xserver - that means it likely advertises an X Display on:1 and you run aps there - it acts as a full X-Server and thus gets all the client requests for drawing, input etc, and translates them. This means an extra layer of abstraction that makes things considerably slower since now all rewquests have to go through another application then later go through X. I toyed with this idea once for the sake of being able not to do 3D but to be able to lkeep miniature icons of applications (their windows) AND keep them up-to-date snapshots in E so you coudl see all programs running miniaturised - thus being able to see when something interesting happend abe be able to maximise them again... but the overhead of having to proxy ALL cals and then maintian a whole X-Server to boot ditched the idea.
I'd like to see how far this gets - but moving 2D apps into a 3D world isnt that useful. I sytill maintain we need a whole 3D windowing system from scratch where apps create 3D objects and allocate 3D areas of space for these objects, not 2D windows of pixel data like its done now. That's where the future is for 3D - but this also hangs on the need for commonly available cheap 3D input devices too - the mouse has become the 2D input device - we ned a 3D one (powerglove or somehting) thats cheap, accurate, and everone has on - also 3D displays (stereoscopic so we can get deth cueues) are also necessary IMHO.
yes - it means you can use KDE aps or components under E and gnome ones and they will both work as expected - so youcan use kfm wiht gnomes panel and have them at least run and display as expected as far as the WM is concerned.
A Window Manager is closer to a desktop system than GNOME is - withotu someone elses WM it is completely useless. you can move or resize a window- no borders, titlebars etc. - eer run X withotu a WM and just apps - well that's what u'd have with gnome - gnome is an application framework - NOT a desktop- KDE is a desktop environemt, E is becoming sa desktop shell (desktop shell being the stuff in a desktop minus the application framework - i'm leaving that up to GNOME and KDE people and they can all happily make their ofice suites and apps all they like and make good ones).
GNOME and KDE are both doing good jobs. they're going to both be using XDND (wel gnome alreayd does since GTK does int is dnd implimentation and KDe is moving to use XDND in their next release) and Enlightenmnet's File Manager when it gets put in will use XDND too.
Slashdot Mirror
You should try E then - as most of what you say is wrong - as of recent E17 in the last 6 months - download the gos ISO and try it first.
Those features were never removed from FVWM or Enlightenment - just you chose to use different WM's that choose to assume you, as a user, are stupid and don't need or want features. You will be confused by since completely incomprihensible features and thus should never have access to them lest you explode from confusion! :)
:)
Just go back to using your favorite WM's and they will keep doing what they always did.
Where does it say you need to be a student? The closest I see is "no corporate entries" - ie a company cannot submit. Doesn't stop someone working from doing one in their own time and submitting as an induvidual?
PNG BETTER for high-traffic? yeah right (the short version). if you are high-traffic that means lots of images downloaded - that means lots of bandwidth. you want to reduce bandwidth - thus reduce image file sizes (or reduce the size and/or number of images on a site). jpeg uses lossy compression that means it will LOSe image content/data in return for compression. in most cases if the image is "realistic" (a photo) and not purely hand-drawn, jpeg produces much smaller file sizes at mostly indistinguishable quality (given a good quality setting) for most people, or acceptible degredation in return for MASSIVE savings in file size. in fact it can be 1/5th the size or even 1/10th the size of the same PNG for the same content and visually be "as good". with jpeg you do not get an alpha channel so it's not useful for cases where you want that, and it's also not useful if the quality loss is not acceptable - but in ALL other cases, jpeg will get you much reduced bandwidth requirements compared to png - the vast majority of the time. i suggest doing some reading up on image compression techniques and image file codecs.
Oh the lack of clue on actual facts is astounding... oh waity. i forget. This is slashdot.
aaah this explains the gartuitously slow code on todays machines. people thinking snprintf is better than strcpy/strcat.
:)
snprintf method takes: 0.571 sec for 1,000,000 iterations, strcpy etc. 0.124 sec. you have to think that every time you do something you choose a method 4+ times slower that no wonder today's software is not appreciably faster on machines 100+ times faster that they were 10 years ago.
code for the test:
#include
#include
int main(int argc, char **argv)
{
int i;
char buf[1024];
char *s1 = "/path/to/whatever/here/to/test";
char *s2 = "a_file_name_goes_here.blah";
for (i = 0; i 1000000; i++)
{
#if 0
snprintf(buf, sizeof(buf), "%s/%s", s1, s2);
#else
strcpy(buf, s1);
strcat(buf, "/");
strcat(buf, s2);
#endif
}
}
you can figure it out
what i need is something like... ooh... a job to DO enlightenment instead of doing it on evenings and weekends. trust me - a manager would be able to do nothing here - he has no resources to work this. they have all gone usefully into building what is the back-end of e17 (itsw rendering, theme, core event layer etc.) and it's paying off now in leaps and bounds.
:)
what you may not realise is - my day job has nothing to do with x, graphics, e, etc. it's rather mundane, BUT i get to see the world and experience life
BWHAHAHHAHAHAHahAHHAHA
:)
ROTFL
HAHAHAHAHHAHAHAHAHAHAHAHAHAHA
hbehehehe
damn
my stomach hurts now.
(BTW - dont have anything against Havoc and Seth at all - maybe they should just pop an eye over E one day - it might give them ideas... help them out)
In what spare time? We already work FULLTIME on E stuff - and fulltime means evenings and weekends. NONE of us get paid to do this fuloltime. If we had that time I'd be helping tomorrow as getting Xrender to not suck (it's software fallbacks be sane in terms of speed) is in our best interests - as well as everyone elses, but until we have that opportunity, we have already written all our own software rendering and it works for us. :( Someone come up with an offer to let us work on this fulltime - then please speak up and contact us. We put our code were out mouths are - always have, always will.
It's BSD - I just think people don't care. I don't care much myself - except everyone runing around as if Cairo, using opengl for 2d rendering etc. is all new stuff and freedesktop.org are the pioneers in doing this on linux etc. etc. etc.
I can say why - it's not "a gnome" or "kde" project - thus it's mostly ignored. As I said - I don't really care much - but I would like to point out - we have implemented, and have runing most of what Seth talks about. It's working, and working at a good speed WITHOUT the need for hardware accel. We CAN use Hardware accel - but see above.
If people want to SEE it working already - check E17 stuff out of CVS - watch the avi's, look at the screenshots, browse the code etc. etc. etc.
Thanks :)
OK - I see another E thread... Time to inject some fact in here (some of this thread so far is fact, some is over-exuberance, some is patently false).
OK - First. E17 has had all the stuff seth is alking about FOR Cairo, GTK+, Qt - ALREADY DONE. Years ago. Been there. Done that. Been wating for 5 years for XRender to stop sucking. Sorry guys. It does suck (in general). Do some benchmarks. We have had OpenGL acclerated rendering for 2D for years. Evas has enabled that long ago. We choose NOT to use it due to 1. most users NOT having accelerated cards capable of drawing well enough for 2D use (all you i8xx users? s3 savage? via unichrome? just ask all wonders of modern ati cards how great their ati closed drivers are in stability? etc.), and 2. driver stability is so bad, using OpenGL is like asking for an instant system freeze. Linux users like to tout how stable it is - give me 5 minutes on any linux machine with nvidia or ati cards... freeze. It has improved over the years - definitely, but it still is unstable - to the point where we support it but don't trust it to enable it by default. All the playing Owen, Seth etc. are doing and talking about, we have done "in principle" years ago - but no one was interested much. The code has been available for years in CVS. Just check the logs.
We have all the fancy "Indiana Jones" effects done NOW. We have the effects engine done (macro-media flash like system we call Edje, specifically designed to do layout, animation and interaction and act as a slave to a widget set/app). We have an accleratable, re-targetable canvas (Evas) that supports Software X rendering (the highest quality and most stable one), OpenGL (very fast if you have dirvers, but lower quality due to OpenGL resampling for scaling down - mipmaps dont fly for 2D), DirectFB, Linux Framebuffer, Qtopia, System Memory, and yes - we have a CAIRO engine. They are all selectable at runtime by the app and compile time too, so none are REQUIREMENTS, just options. Now just for your info - on every machine I have (1 laptop, 3 desktops - nvidia, ati, i865 and g400 gfx cards) Evas's Software X engine is in the order of 20-40 TIMES faster than Cairo. I can go into details as to WHY and the Cairo devs know and agree as to why (we discussed this - thats why i wrote the engine hooks as a test case) - but first before everyone runs around half-cocked, get some facts on the viability of these things. Evas can pull the same tricks Cairo does via glitz - use OpenGL. We have been doing this for years. We consider it too unstable for production use at all. Punting everything via OpenGL is not a walk in the palk, and has its drawbacks - if you do, WITHOUT a good software fallback system, you have just left every user of a non nvidia card in the stone-age. We do not believe that is a viable thing. Sure - SUPPORT modern cards and get acceleration from them, but don't alienate those with older cards and older systems. At this stage the only rendering engine I have seen to date that can provide the same visuals AND at an acceptible speed is Evas, and still take advantage of modern GPU's via any API made available.
We are doing most of what Seth "dreams of" already. Have been doing so for years. And we have more on our TODO list. UNLIKE relying on CAIRO etc. we can run fast on LEGACY systems WITHOUT special X extensions, and run usably fast (see testimonials on people on 400Mhz or below boxes). We even target embedded devices with our engines (50-200Mzh ARM CPU's). We have an abstracted engine system so we can slide in any rendering technology when it becomes usable. We are WAITING for XRender to become usable (en masse - not just in 1 monolithic xserver for 1 subset of chipsets). We happily continue with the rest of our design and code and dreams being able to bide our time and wait because we have a usable software layer already. We don't RELY on NEEDING a hardware layer. We CAN use it. We CHOOSE not to. See above as to why.
whatevere.
the day you contribute to opensource - let me know. put up or shut up.
1. the xserver was severely slowed down thanks to xvidcap hammering x to capture pixels (e17 was runing inside xnest which was running inside x, and xnest basicaly nukes extensions so all the speedups you get on a real x are gone and the extra indirections really hurt). 2 it's encoding a video realtime while e17 running and xvidcap is hammering x to grab pixels, 3. no it wont be faster not animating as the window pops up instantly and reacts instantly - you just get to see the animation. i like it and its insanely smooth "on a real display" the video is just an indication. get it, install it, run it yourself to see what i mean. the video does not do it justice. sure - you can remove the animation - no code changes needed. it's part of the theme. themes can animate and transition as they like. also the "it uses opengl" comments are wrong. it *CAN* use opengl *IF* it inits using opengl to render. we have a perfectly fast software rendering engine that beats the pants off most things around. all the exmaples you see all use the software renderer. no opengl or hardware help. in fact our preferred renderer is software. its 1. more reliable (stability) than opengl, 2. higher quality than opengl or xrender, and 3. in most usage scenarios much faster and smoother than opengl or xrender - even IF opengl is hardware accelerated (due to lock contention, DRI etc).
It had pagers and virtual desktops in multiple incarnations and ways. I will admit I have not read ALL of thepatent claim - just about half of it. I understand legalese and some of the claims in the patent are prior art. Why? I wrote the code myself to do just that in enlightenment. But this is some of them. It would be easy to prove prior art - just give me a day in court :)
Others I haven't actually seen before, though I would say they do fall under "obvious to someone skilled in the art". Well they are obvious to me - several were always on my "i'd love to do that" list and i had on the cards, but simply X didnt provide the horsepower or api to do it, so it was left out for practical reasons. They are simple effects like "take a snapshot of your screen and then just scale it up and down as an animation transition". It's really BASIC stuff done repeatedly in many ways. E has done this for pagers, well parts of them. It did it with induvidual windows - it'd scale and zoom in on a window as you moused over it (within the pager) so you could better make out the thumbnail contents.
Now what I don't know is if you can deny a claim when sufficient parts of it art prior art and most of the rest is obvious to someone skilled in the art.
IMHO the USPTO should try and keep some experts in fields on retainer - at the very least start a search on existing experts who work and develop/create within those fields. if they get an application that falls within that field, fire off some e-mails and ask the people who are the real experts for known prior art or obvious. The USPTO calls the final shots, but at least they get some good informed responses. If they wanted guaranteed response times they could pay them on retainer too. Since it is a filed patent application and public knowledge, there is no harm in making these questions public BEFORE it gets granted and then has to be tested in court.
Ohhhhhhhhh I so agree with you! :)
well just a correcttion. evas has several rendering engines:
1. software (it uses your cpu and does all the work in the program, not in X. it will use mmx if you have it - its fast and usable and is the default)
2. x11 (xaa - uses normal x calls - all of which go through xaa. it uses normal x lines, polygons, rectanlges, pixmaps etc.)
3. image (again software - client side - but renders to local client side memory too as a final output - handy for being able to save the canavs to a file such as a png or jpg, or being able to do other thngs with it)
4. render (uses xrender extension - so far i only have stubs. i have some of it going locally here - but not enough to bother committing to cvs)
5. hardware opengl (uses opengl for the back end rendering - you take it from there)
the application gets to ask evas for the rendering engine it wants to use. if its not available (no opengl on the display system or it wasn't compiled in, or the render extension is missing etc.) it will always fall back to software rendering.
anyway. hope that clears things up a bit.
well actually x doesnt do alpha channels for windows - the window you see there just as "no background" for isn't background which means if you map the window it inherits the current framebuffer contents. you are only seeing x doing alpha compositing.. and no - keith hasn't thought of everything. he's thought of a fair bit.. but not everything. currently image transforms are unimplimented. there isn't even an api call for them. i'm tryng to get at last this fixed :)
the fact that evas has is "canvas" is nothing new. it's an ancient idea. the fact that i did start it off simple and dind't go completely bezerk with abilities and features (display postscript, display pdf) - just kept the core and basics, meant that i could actually finish it in time to use it for writing the app i needed it for: e 0.17 AND it menat i could also accelerate it via multiple back end rendering paths. it's quiteodd too the apeolpe assume it is ONLY opengl - in fact i woudl not suggest using the gl backed rendering engine on anything but an nvidia driver because so far no driver i have found comes even clsoe to being stable enough or complete enough. but nvidia is about the closest. my own software rendering (imlib2 does that for evas) which is quite fast is what i normally use for evas - so you don't NEED hardware. you can use normal X11 pixmaps and X primitives as a rendering back end for evas too. this keeps it simple - but still makes it able to be extended easily, and has allowed me to make it work and work well in a relatively short period of time with a relatively small amount of resources.
:) the end result is a canvas that is fast.. hardware accelerated or not, that does its primitives well and does the job i need... and can be improved in time with no effect on the programs using it other than positive ones (new features... or faster & better quality rendering etc.)
:)
:)
that is what the power is.. and it can be easily extended. new object types can be added - new things like having clipping paths could be done, extra object attributes can eb added that affect their display.. but the more complex the feature the harder it is to support in the back end rendering... and the less likely it is to be able to be hardware accelerated and instead have to be done more slowly in software - even the software optimizations are lezz liekly to be effective the more complex it is. thus i choose to only impliment what i really need - and that can go a surprisingly long way
evas solves the problem in an elegant way... and rememebr it isn't the same as dps/dpdf - its a canvas. that is a different concept.
i also know a bit more about apples display technology than you think - it defintiely is pretty - and yes... i'm not going to comment much in detail on it as i dont, imho, think i know enough details to make a very concise sumamry of it and get it right 100%. but i know enough to know what they are doing (approximately) and why etc.
evas is a different technology - it is much closer to the java canvas, tk canavs, gnome or qt canvases. it can be extended and wrapped and made more pwoerful with layers ontop that use it as an optimized rendering system... and that is incendentally one of the side projects happening right now
anyway.. just thought i'd comment a bit - don't want to flame - just want to fill in the gaps ininformation that wasn't provided for you before
..." I do like the flexibility of E and the fact that it can be quite efficicient when you want it to be, but that pager is the biggest CPU hog ever. Its pretty, but I don't see enough functionality to justify the resources it demands, even
:) as has been noted almost everyhting is E is turn-off-able - if the feature is a bit too much for your box.. it can be turned off - for my mahcines it was barely noticeable that it was turned on.. :) just a remiinder that E is configurable.. if a feature "offends" you - visually, cpu-wise etc.. u can turn it off :)
:)
on a reasonably fast machine.
"
turn snapshottign off - you'll find them as fast as any other pager
BTW - dunac was noting the memeory footprint of the code i think in his VM comment - so even if the code is bigger - unused code pages are never paged in form disk.. thus they may appera to take ram in PS and TOP - but infact they don't = if that page of code is not executed
OK.
Cluestick time.
E was around LONG before GNOME was. E started back in lat '96 and actually had working code back then.
E had pagers long before there was a gnome spec to do them - yes - they dissapeared for a while because that bit of code was being rewroked. The end result was they came back and people loved them.
This is not an ego question - I don't knwo where you got that idea. E was never desiigned to be minimalistic for gnome - I walways had a vision of having a desktop of my very own that woudl feel like my good old amiga workbench but on steroids - why shoudl I stop just because gnome appears? E still manages apps - any wm does that.
E was used to ship with GNOME because no other WM was fast enought to come aroudn and support gnome WM hints - E wasn't designed to be minimalistic - I didn gnome work because I was paid to do it - not voluntarily because I liked it - I was hired by Red Hat and basically turned up and found out "guess what - your'e working on gnome!" - which was infact the kind of project i'd been heading towards for a while with E - how yould you liek someone to destory youre hopes and dreams and ideas by turnign your project you've been working on for ages and been dreaming up for years into a spare tyre? some of us beleive it or not are more resiliant than that - we dont give up. e just supported gnome - it was never gnome's wm. if you had any idea you'll notice that i spent months ont he gnome list statig that gnome needed their own wm - but no-one listened or agreed - until it was too late and they realised they needed one. i think it may infatc be more arrogance on gnome's part thinking they can work with any wm withotu any formm of extra communication happening because they dont realise the scope of freedom icccm gives a wm. to get gauarnteed behavior they need their own wm - otherwise there is no guarantee.
e is getting a file manager primarily because i dont like gmc or kfm - and i dont like nautilus. they all feel so windows explorer-like. many people might liek that - but i dont. i'm not here to advocate opensoruce or produce "the linux desktop" or make gnome better or such - gnome is doign a more than admirable job in developing an application development layer - it's execllent work - so is kde. i think they shoudl both continue on that goal and make it better. but E is not gnome - it's not part of gnome - it never was. opensource gives anyone the freedome to come up with their own solution - and that's what i'm doing - that's what gnome is doign and that's what kde is doing - thats' what window maker is doing... do you want to deny people their freedom of expression?
think about it a bit more. maybe you've never had somehting you've created your'e proud of - then you just don't know the feeling. it's like haveing a child and watching them grow up. E was never meant for gnome - our goals had way too much overlap. i wasnt goign to relent on my goals and ideas and dreams just bcause gnome needed a wm.
All I have to say is - congratulatiosn and well done. Keep workign oon RXO - the more competition, the better - it means i wont have time to get lazy. i'm goign to check this out and have a look.
i wish people would be more positive and offer encouragement not disparagement just because someone has a project they want to work on and it isnt what you're wishing was "the thing". let people have their projects - often they have a good reason they started it.. and sometimes they are so far into it that they aren't just goign to give up because someone else has a similar project...
Well done ROX - keep it up... Glad to see more stuff around.
-> Hey, how does this work out? I was under the
:1 and you run aps there - it acts as a full X-Server and thus gets all the client requests for drawing, input etc, and translates them. This means an extra layer of abstraction that makes things considerably slower since now all rewquests have to go through another application then later go through X. I toyed with this idea once for the sake of being able not to do 3D but to be able to lkeep miniature icons of applications (their windows) AND keep them up-to-date snapshots in E so you coudl see all programs running miniaturised - thus being able to see when something interesting happend abe be able to maximise them again... but the overhead of having to proxy ALL cals and then maintian a whole X-Server to boot ditched the idea.
-> impression that the WM just handles the border,
-> resizing, etc. of Windows in X. If
-> that's the case, then how does 3DWM show a
-> window from a different angle? Wouldn't it be
-> more like a replacement for the X
-> server?
yup - what you see here is NOT a Window Manager the ONLy way to accomplish this is for the "so called wm" to be a proxy Xserver - that means it likely advertises an X Display on
I'd like to see how far this gets - but moving 2D apps into a 3D world isnt that useful. I sytill maintain we need a whole 3D windowing system from scratch where apps create 3D objects and allocate 3D areas of space for these objects, not 2D windows of pixel data like its done now. That's where the future is for 3D - but this also hangs on the need for commonly available cheap 3D input devices too - the mouse has become the 2D input device - we ned a 3D one (powerglove or somehting) thats cheap, accurate, and everone has on - also 3D displays (stereoscopic so we can get deth cueues) are also necessary IMHO.
yes - it means you can use KDE aps or components under E and gnome ones and they will both work as expected - so youcan use kfm wiht gnomes panel and have them at least run and display as expected as far as the WM is concerned.
A Window Manager is closer to a desktop system than GNOME is - withotu someone elses WM it is completely useless. you can move or resize a window- no borders, titlebars etc. - eer run X withotu a WM and just apps - well that's what u'd have with gnome - gnome is an application framework - NOT a desktop- KDE is a desktop environemt, E is becoming sa desktop shell (desktop shell being the stuff in a desktop minus the application framework - i'm leaving that up to GNOME and KDE people and they can all happily make their ofice suites and apps all they like and make good ones).
GNOME and KDE are both doing good jobs. they're going to both be using XDND (wel gnome alreayd does since GTK does int is dnd implimentation and KDe is moving to use XDND in their next release) and Enlightenmnet's File Manager when it gets put in will use XDND too.