Re: Application modal transients windows

[raster rasterman com]

On  8 Nov, Marko Macek scribbled:
->  raster@rasterman.com wrote:
->  
->  > If the window manager gets a property notify for this property it
->  > shoudl re-read the property data contents and any visible icons
->  > displays for this window shoudl be then re-rendered and updated so the
->  > user can see the updated version.
->  > 
->  > Thsi property should only be set on top-level windows and not on group
->  > leader windows that are unmapped.
->  > 
->  > The window manager is free to res-cale the icons data to fit the
->  > available space for it to be displayed. it may re-color, rmap and
->  > dither the icosn too according to user preferences for color image
->  > rendering quality etc.
->  
->  I have a few comments (#1 most important):
->      1. scaled icons absolutely suck if small (getting nice 16x16 icons
->  from 32x32 or 64x64 is likely to produce ugly icons). Good icons are
->  pixel-perfect and scaling is not the way to get them.

then ythe apo shoudl provide the closest size to the icon size hint.

to be honest this is impractical.. wms have variable sizes for icon
needs - for big icons on a dresktop, small icons in titlebars - maybe
medium sized.... they all vary and some like the titlebar cant be fixed
since they may depend on font size and other factors. so if a WM is to
do it right most wms will have to scale anyway. agreed arbitarily
scaled icons dont always look right - but no-one is goign to be willing
to draw their icons in N diferent sizes just to please the WM or the
user prefes so scaling has to be accepted as a way of dealing with this.

hell - programmers are even reluctant to even draw a single icon - they
prefer to either draw 3 lines and a box in gimp, use an alreayd drawn
icon, or not have one at all - so if we get even one image out of them
we're lucky.

->      2. I don't plan to support rendering ARGB icons at this time (see
->  3).
->      3. When X has support for ARGB (and rendering of them), this
->  property will be a problem because the WM will have to download the data
->  and then upload the image or the data for rendering. This wouldn't be a
->  problem if we just have pixmaps in the structure.

it will take a while before this kind of ability in X is anwhere near
standard so i dont think we shoudl be holding our breath. one day it
will come - but in the meatime we have a way of making it better.

also in addition. lets say the app provides a pixmap and a mask. it has
2 first:
decode image data form disk or ram
create pixmap
create mask
(assume local client)
creat XshmImage
create mask XShmImage
fill XshmImage
fill Mask XshmImage
put image and maks ShmImages to pixmaps
destroy shm Images
set property
wm needs to read property
wm copies/pastes pixmap id

this requires 1 decode, 1 render (assuming it can fill both mask and
image ShmImages in one go) and 7 round trips to the server

if tis argb data:

decode image data
set property
wm reads property
wm creates pixmap and mask
wm creates ShmImage
wm creates ShmImage mask
wm fill ShmImage
wm fill ShmImage mask
wm put ShmImage & mask
wm destroy ShmImage & mask
wm paste pixmap

this requires 1 decode, 1 render and also 7 switches. its no less
efficient - the data sizes we're talking abotu are so small its
irrelevant - latency and roundtrips are the problem, not bandwidth.

both ways are the same - but with the second there si a LOT more power
available - not add to the fact several wms and mroe in future will
ahve to add extra phases of converitng the pixmap and maks back to ARGB
for re-rendering in a new visual or a pixmap or just onto another
larger ARGB space... thats mroe roudn trips for method 1 - thus method
2 - ARGB data means on average the leats numebr of round trips. this
also have more distinct advantages:

color and colormaps

for multi-depth displays with wm has the choice of the visual to use
for the icon - and the colormap if not a turecolor visual (ok direct
color is another matter) - with method 1 it has no choice and may have
to do the conversion step above unless it actually has to use shaped
windows all over oint he visual thats the default (root). so mehtod 2
affords much mroe freedom, beter image quality, less roudn trips to the
server on average, and considering on my box i can get around 10,000
roudn trips a second (all i'm doing is a tight for loop with an XSync
in it) and i can manage to render 22,000,000 pixels a second form ARGb
to a drawable - i can do 21,000 32x32 icons a second (I've implimented
XshmImage caching in imlib 2 so it doesnt have to create and destroy
XShmimages all the tiem if it doesnt want to). thus i can actually get
better performance than method 1 by using method 2 because i can cut out
3 round trips :) 

thus i still think from a sheer efficiency and technical standpoint the
ARGB data in a property is the most efficent and also highest-quality
AND most flexible method. the app shoudl just provide the icon in the
closest size it can to the icon size specified by the wm. :)

->      4. If the wm doesn't process the icon data, sharing the icons is
->  possible if client uploads the data to the server.

um sharing between who? the wm is the one displaying the data... it
will share it amongst itself. :) ok mayeb taskbars as separate apsp -
but then we have the philosophy differenbce where i beleive all the
shell functionality shoudl be a in a single X client sinc eit can share
that data then since it alreayd owns it and created it and knows about
it - withotu any ipc mechanism and locking/referencing system. but
thats another matter.

->  Mark

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com     raster@valinux.com
                                    raster@enlightenment.org raster@linux.com
				    raster@zip.com.au