On 11 Jun, Sebastien Carpe shouted:
-> Oh well, i guess i'm about the only to care about that but i was just
-> wondering about what would be the status in terms of speed and
-> efficiency.
-> E is currently known to be the nicest looking WM on thw web, but also
-> to be really heavy. I've read some lines (from Raster, bite me if i'm
-> wrong) telling the speed improvement was one of the aim of 0.14 (using
-> hash table for raw tables was an example).
-> So well, at Home, my PII run E 13 just fine (nothing heavy or
-> whatever) but here, at work, my HPUX 9000/712 is really slower and
-> running E 0.12.x (i only got this one handy when i tried) was too
-> heavy (moving windows was just pain in da ass - using the DEFAULT
-> theme -).
-> So well, i was just wondering if there was some test being done about
-> speed improvement, or may be just a "yes it's really faster"....
AH! I see it's about that time again... time to take a quick tour of
comuter graphics, the X-Window system and X programs and how they all
interact... so here we go on a journey....
1. X is Client-server. that means anything grpahcis-wise involves a
request by a client being sent down a connection to the server and the
server then honoring that request. When I send a pixmap (an image) to
the server generally that image is transferred byte by byte down this
connection - ie if i'm runign in 16bpp (16 bits per pixel) and i have
to transfer a 1152x900 pixmap to the srever I have to dump just under
2Mb (1152x900x2 bytes) of data to the server via this socket connection
- ie .. slow. So X has methods of speeding this up. It's called the
MIT-SHM (XShm) extension that allows an Xclient and the X server to
negotiate a chunk of shared memory that is shared between client and
server. This means with a little protocol work I can negotiate a 2Mb
chunk of memory and then send a request to the Xsrever "Read this
memory chunk now" and it read the memory directly in order to display
it - MUCH MUCH MUCH faster. There are several variations - Shared
Images and Shared Pixmaps Shared Pixmaps are a touch (about 10%-15%)
faster than shared images - probabyl due to a more "native" and more
easilyl usable format for the Xserver. Imlib automatically will chose
to use the sockjet, Shared Image or Shared pixmap method to get image
data to the server wherever it can to make things fast - but keeping in
mind the users preferences int heir .imrc file. Imlbi does all thsi
magic quietly in the backgorudn and I in Enlightenment do not need to
know nor care how this happens. it's transparent to me - just thank god
I write Imlib and so I can make it do exactly what I want.. but to any
programmer using it it's simple "magic" that gets you a pixmap in the
end. Now add to this the added work of having to take 24-bit pixel data
and for EVERY pixel (for an 1152x900 image thats abotu 1 million
pixels) having to read the 3 bytes of RGB data - then work out if i
have to dither (which involves picking a colsest matched color, adding
the error to the surrounding 4 pixels to the right and below when
dithering) or to ordered dither, or to map the RGB bytes into a single
16bpp value or a 15bpp value or somehting else... then write this to a
memoyr buffer, then when done copy the memory buffer to X so it can
then copy it to the framebuffer.. you get to realise just how much work
is needed to get an image onto the display liek for a root backround or
parts of a window's border etc. Slower machines mean this becomes
slower - especially if the processor copying the data to the
framebuffer has to contend wiht wait cycles for the DAc chips readint
he framebuffer to generate a video signal at the same time (DRAM cards
onyl allow one access ata time - ie eithe read/write by cpu Or read by
DAC - thus dram cards will give you a VERY SLOw display especially if
the refresh rate is high - meaning the DAC reads more often more quickyl
leaving less cycles for the CPU to write). Now keepign that in mind..
the obvious optimisations I have alreday donw for you (cahcing data int
he Xserver wherever possible rather than re-sending across the
connection and more... but sooner or later it's the user that matters -
E will use imlib and E will do what you tell it to. If you have a
full-screen backdroup - adifferent one for each and every desktop of
course things will get slow chaning desktosp and laoding in backgrounds
- having to dump the data to the xserver for each desktop and copy the
data to the framebuffer on switches - use the same backgroudn and use a
small tilebale image to speed htings up - E wont stop you form doign
stupid things.. if your mahcne can handle 20 different fullscreen
backdrops and not twitch - sure.. it will let you.. but expectign that
to work on a small cpu=hampered memory-hamperd machine is sheer
insanity. It isn't E thats heavy.. its the configuration it's told to
use. Now if people realise this for once maybe they'll modify their WM
settings to match their machines and not expect an ancient slow machine
to perform as well as a fast swanky new beast box. Thsi is one of the
common mistakes made by the ignorant (many people on the WindowMaker
list and that community make this very tiresom obvious and brain-dead
mistake) - they think just cause somehting is capable of doign a lot
and when you ask it to its slow the thing (in this case E) is broken
and bloated - it is not. ask ti to do very little and it will do very
little and be fast, as those who have done so will attest to.
2. The X Shape extension. The shape extension in X isnt exactly the
most optimised beats.. E and imlib cant' do much abotu this.. tis
mainyl server-side, not client side. The shape extension works as
follows: when you have a shape mask for a window it onyl has an option
of opaque or transparent - ie 1 bit (on or off). What the shape
extension does is it creates a series of clipping rectangles in
horizontal strips like:
Mask:
### ####
########
########
###########
###########
### #######
#### #######
#### ####
Rects:
(note: +==+ is a 4-pixel long rect thats 1 pixel high,
+----+ is a 6 pixel long 2 pixel high rect
+----+)
+=+ +==+
+------+
+------+
+---------+
+---------+
+=+ +-----+
+--+ +-----+
+--+ +==+
notice how the shape suddenly became 8 rectangles - luckily not too
many.. nwo just imagine large shapemasks wiht complex shapes (the worst
case scenario woudlbe one with a checkerboartd or verticl strip pattern
like:
# # # # # # # #
# # # # # # # #
# # # # # # # #
# # # # # # # #
)
now you can imagine how slow this has to get if you have complex shapes
and X has to use a hige list of rectangles to use to clip its drawing
functions... and when doign redraws etc.. so if you have a fast machne
you can probably afford to have more complex shapes - but for sanity
keep shapes SIMPLE keeping in mind the above way that X does its
shapes. Remember to design your desktop within the abilites of your
machine - E wont stop you form pushing your mahcine beyond what it
reasonably can be expected to do - thats up to you to tame things down.
YEs another factor contributing to the myth that "E is slow" - its
not.. its the configuration you use. Use a simplistic ona dn E can be
very fast.
3. USE THE OPTIONS. E has many options.. often the slower, yet prettier
options are turned on by default - unlike other WM's E's default setup
is designed to show-off as much as possible - if things are slowign
your box down .. TURN THEM OFF - E has config files.. USE THEM!
4. 0.14 and beyond. 0.13.x and below have been abandoned. what happened
bakc there is history. E 0.14 mayaswell be a new window manager under a
new name simply written by the same people. It is a completely new set
of code - new routines for everyhting - everyhting is new. As a result
E 0.14 is much liek E DR-0.1 - New. and evolving. We have redesigned
everyhting as a result fo learning a lot before. It is missing a lot of
stuff just liek DR 0.1 of E didn thave menus, didnt' have virtual
desktops, didn't have icons, etc... but they came along sooner or later
- and it will happen with 0.14. You may have to wait, but 0.14 alreday
has much much much mroe than Dr 0.1 of E ever had. It is also written
to be optimised - it frees up ememory that hasnt been used for a while
cleaningup after stupid users who dont make lean configurations. It
doesnt do stuff unless it has to. It tried to use the Xserver hardware
acceleration where possible to speed things up by simply doign things a
different way. 0.14 is a new kettel of fish. Live with it. Hopefulyl it
will become the best WM money can't buy. We dont know. We care what
users think - and we try. We arn't god - we arne't perfect - we make
mistakes - but we try and minimise them - please help us. give us
SENSIBLE suggestions - and sugest them AFTEr resarching their
possabilites.. dont jsut say "i want semi-transparent windows" - look
at the facts - at how X works.. and what woudl be needed to impliment
such a thing.. then and only then if it seesm feasible - suggest it. If
theres a bug.. PLEASe dont jsut say "bah E sux.. it died" - PLEASe
HELP. Run E under gdb - examine backtraces - variable etc.. at leats
try and narrow down the search and help us find them. I've been doing
this non-stop thru E 0.14's development.. hunting these down wherever I
can - I might have missed some. Please help us find them and remove
them. After 0.14 We want a development team - not just people talkign
but serious peopel who want to actualy put a hand in on shapeign their
desktop. We want people to help make releases and make them work on all
platforms. We want people to help find mugs - we ant people to help
write code and features... thus these core peolpe will get CVS write
access. If you are SERIOUS abotu this - and you think you can work in a
team - please contact me or mandrake when we realease 0.14. We want to
co-ordinate and get things moving. Oneday E may be your main desktop
feature. If you can code and want a say in it.. speak up.
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
[EMAIL PROTECTED] /\___ /\ ___/||\___ ____/|/\___ [EMAIL PROTECTED]
Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
+1 (919) 929 9443, 801 4392 For pure Enlightenmenthttp://www.rasterman.com/
-
To unsubscribe from this list send mail to: [EMAIL PROTECTED]
with the message contents: unsubscribe e-develop
