From: <ra...@ra...> - 2001-04-16 07:35:07
|
On 15 Apr, Tom Gilbert scribbled: > * Patrick Fritzsch (lu...@gm...) wrote: > > > > hi > > i am not sure, if it should be the target to create a new > > "application packet" for linux, versus Gnome and KDE. > > Ewl will be there, but shouldnt we limit its use to E conf programms and > > really E related stuff? > > there is already so much trouble with the interoperability between > > Gnome and KDE. i dont think linux needs a third player in this round. > > Otherwise i think, when do we have EOffice..:) > > there is already good code everywhere...there is no need for a third > > rewrite of it. > > Agreed. There is enough work to do on said "desktop shell". If you want > to hack, get involved in that. Rewriting every app under the sun using > evas is bad for various reasons. i agree with "rewritign every app under the sun" with you fully. i dont aim to do that myself - but if poeple choose to write an app because the set of apps out there simply doenst meet their needs or wants and "fixing" the existing set of apps is infesible - they should be allowed to do whaqtever they feel is right - but i agrede - "Eoffice" is not on my drawing board at all. > 1) What a waste of effort. Do you actually _want_ to be part of > fracturing the linux community further? We are just starting to > standardise on a set of libraries and they are just starting to > intercommunicate. What a waste to blow it all away now. this doesnt fracture at all. its just another X application - no different to one you would write in Xlib - its not incompatible - its just built using a different set of base tools. > 2) Evas is _NOT_ the solution to every problem in the world, and it's true. very true. > _not_ ideal for every application. It's a canvas, you use it when you > need a canvas. You seen people implementing entire apps using only a > gnome-canvas? No. Because it's not fit-to-task. For a wide variety of > applications, evas is not the right tool for the job. It's memory/cache > management is too basic to work sensibly in every application. > > For example. You have an program that opens a window with a large image > in the bg. The image takes up 8Mb of RAM uncompressed (reasonable for a > screen-sized image). Your app then, in the process of running, opens and > shows 50-odd images (buttons, sub-screens, images etc) averaging 500Kb > each. Now, if you write the app using a toolkit such as gtk or whatever, > you manage the images yourself. You'll load the bg and keep it resident > in ram, after all, you need it for every redraw right? > But you'll load each subscreen/image/button as you need it and free when > it's done with (subscreen closed or whatever). At any time, your app > might be needing 8Mb RAM for the bg plus say 10 images for the current > subscreen - another 5Mb. That's 13Mb just for graphics, but that's okay > - this is a graphical app right? So let's do it in evas. yup. this is true. > In evas the only control you get is the cache size. You know you need > 13Mb-ish at any one time, so you set the cache to that. Big trouble. > Once you load a certain number of images, the bg gets pushed out of the > cache. Now you get "cache-thrashing". So evas loads the bg _every_ time > it renders it. Your app is now piss-slow. How do you counter this? You > have to set the evas cache to the maximum uncompressed size of all the > graphics you'll use in your app. 8Mb + 50x500Kb. 33Mb. That's just for > graphics, let alone evas's other internal data, and all the GL stuff > that's created on the fly if you use that backend. > > This is a dumb example but it shows the point. For any remotely complex > application, the cache handling is too basic to be useful and there's no > way not to use it. > > Evas is a canvas. Use it for canvas-like things (but bare in mind it > doesn't do rotation or zooming or curves or other canvas-style things) it does do zooming :) rotation is in theory possible but i havent implimented it due to complexity issues - and well yeah.. no curves.. thoguht i coudl add curve primitives - but yes it doesnt do these.. at the moment. > but for chrissake don't write every app in the world using it when it > makes no sense to do so. The last thing we need is a 100 mp3 players, cd > players and email apps that swallow memory like hogs simply by managing > it badly. envas... envas... envas... :) > Evas was written for E17, principly to show files as icons in a window. > It's pretty, but it's not fit for all the applications you people are > trying to squeeze it into. yup. thats what i designe dit for - its caching scheme was based on my "what if i have a dir of 6000 icons and i want to have them all as obejcts but only at any one time render a portion.. i dont want to always manage to cahce the right ones figure what id and dont need to cache etc." so i put in the system thats' there.. i'm currently debating changgin the back end to be more persistant in keping things in ram and using the cache as a real cache (ie image objects and txt objects within the visiblre canvas viewport will have their data retained in ram regardless and onyl object transient between visible and not visible in the vieport wil be subject to the cache) - this should solve my problme - but this si why evas is stil at 0.0.5 :) i ave to iron this out - i dont want evas eating rsm for every objetc u create and its image data - especially if that object never gets displayed, but i want performance. i have to straddle a fine line here - you're right abotu the caveats thouhg - but this kind of stuff CAN be sovles farily easily. apps using evas dont even have to knwo the difference. personally i would sugest cache sizes shoudl b auser configurable things per app so the app then needs to knwo nothing and just let users twiddle (or wizarde programs that determine performance by twiddling the cache size and from that give u a sugested cache size) anyway... also i'd liek to point out it was a few years ago i was talkign to owen taylow - who basically maintains gtk these days, and he was quite into the idea of moving gtk to use a canvas abstraction for rendering as it woudl be so much more efficient sand easier to manage - and woudl get rid of all the rendering problems they have no w- but the task of moving gtk to it is just too mammoth. you can use a canvas for a lot of stuff - and it is perfectyl feasible to build a widget set using a cavas - more than most people think, but yes - it still have caveats and limitations :) it's still an interesting experiment though and i want to see it happen. -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... VA Linux Systems ra...@de... Mobile Phone: +1 408 887 3163 Work Phone: +1 510 687 7069 |