Re: What's wrong with wayland?
On Sun, Feb 20, 2011 at 2:35 PM, Enrico Weigelt wrote: > * Marty Jack schrieb: > >> If remote clients is your thing, instead of forecasting doom >> because the old way may not work any more, first off, nothing >> stops someone from writing a thing that listens on port 6000 >> and acts just like a remote X server only it is a Wayland >> client, and second off, > > At this point, I fail to see the real benefit of Wayland, at > least from user or infrastructure view. (yes, having the hw > and composition part of the fat Xserver IMHO is a good thing > from sw-architectural view). > > One thing that annoys me is that the current design papers > explicitly take remoting out of the picture (almost declares > that obsolete or tells people to use insufficient workarounds > like VNC) and delegates a lot of things to individual clients > (so in the end introducing massive code and data duplications). There is an excellent emerging protocol for app remoting called HTML5. Code your app as an HTML5 app and problem solved. Nothing stops you from running both the client and server parts on a single machine. Gee - we just did that with the Xserver. If you do this your app is cross platform and also able to be immediately used in a cloud environment. HTML5 graphics can do everything desktop graphics do so there is no real loss in changing your coding model. Coding for the existing desktop model is backwards looking. HTML5 is building for the future. Look at ChromeOS. HTML5 based apps are the only kind of app that you can run. If you need extreme graphics speed check out Google's NaCl project. > >> nothing stops someone from redesigning and rethinking what >> the proper remote protocol is, > > I'd start with an proper model before starting to think about > an specific protocol: why should a client still be responsible > for drawing, instead of just describing what it wants to have > displays (eg. an scene graph or something more hi-level) ? > > Typical GUI applications have concepts of windows (and windows > within windows), widgets, etc. Those are all objects that can > be described formally and rendered in a hi-level display server. > This also would allow large savings of now heavily duplicated > code and data in the individual clients. > > 8 1/2 could be a interesting conceptional starting point. > >> using modern encryption and compression techniques and whatever >> else is needed to get a VNC like solution that performs well >> and is secure. > > VNC can not be done right that way, as it's conceptionally > meant for a whole different purpose: it operates on screen level. > It has no idea windows, server-side resource objects, etc. > Simply lacks this information. > > > cu > -- > -- > Enrico Weigelt, metux IT service -- http://www.metux.de/ > > phone: +49 36207 519931 email: [email protected] > mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 > -- > Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme > ------ > ___ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jon Smirl [email protected] ___ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: subpixel rendering in wayland?
On Tue, Mar 1, 2011 at 7:40 AM, Michal Suchanek wrote: > Hello, > > I was just wondering about subpixel rendering and how is that going do > be done in Wayland. There are discussions about this in the archives. My understanding of the problem requires for Wayland to provide the window transformation function and the screen geometry to the app (which way the subpixels run), and then let the app generate a final, transformed, subpixel antialiased bitmap. Wayland would only do straight copies of this bitmap to the display surface since doing any more transforms will mess up the antialiasing. In this case apps (via toolkit libs) need to know how to do subpixel antialiasing for output buffers that may be twisted in 3D space. The projection of the transformed buffer is not necessarily a rectangle and a depth buffer is needed. A legacy mode could be provided where apps only render into rectangles and then Wayland does the transform. The app still needs the screen geometry info to know which way the subpixels run. That info is passed into Freetype. Wayland can decide to do further transforms to this buffer knowing that it will mess up the antialiasing. As far as I know no one is looking at the first case. It would be interesting to see some experimentation with adding improved antialiasing to the various toolkits. A simple way to see the impact of improved antialiasing is a cover flow type display for switching between windows. The windows on the sides have been twisted in 3D space and their projections are now trapezoids. > > In X an application is supposed to ask xrandr about current screen > layout, determine on what screen(s) the window is placed, and use the > subpixel order and screen rotation information to figure out how to > lay out subpixels in antialiased objects. > > To the best of my knowledge no X toolkit does this. Last time I tried > to look there was a global setting of horizontal RGB vs BGR so I > turned off subpixel rendering completely. > > Wayland currently does not support multiscreen but rotation should be > already possible. > > Is there any provision for applications to get the information about > subpixel layout of their windows and is there any toolkit for Wayland > that honors it? Are there any tests in place that would make sure > toolkits render subpixels properly in various situations? > > Or is subpixel rendering considered superfluous and unsupported by wayland? > > Thanks > > Michal > ___ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jon Smirl [email protected] ___ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: subpixel rendering in wayland?
On Tue, Mar 1, 2011 at 1:37 PM, Bill Spitzak wrote: > A Wayland compositor *could* resample the source images knowing about the > positions of the rgb subpixels on the output device. For instance the > filtering could shift the source transform 1/3 pixel right for the red and > 1/3 pixel to the left for the blue, to compensate for where the centers of > these LCDs are. Further (and more complex) filtering will be needed to avoid > color fringing in high-contrast areas. It would be interesting to figure out how to use the full-screen anti-aliasing hardware available on most graphics cards. But I don't see any way to do that other than by having the app draw the final transformed window including a depth buffer. Getting that to work could provide 16x over sampling. I don't think is is feasible to keep intermediate bitmaps at 16x resolution and then let Wayland filter down, but it may be possible. Graphics cards do have lots of memory and desktops don't use much of it. > > It is also likely that the client wants to render an image to display at 1:1 > scale on a particular subpixel screen (i.e it uses freetype's subpixel > rendering). In this case the filtering also has to try to invert the 1/3 > shifts and color fringing filtering that the client did. Ideally these will > cancel out if the scale is the same and the input and output subpixel > arrangement is the same. > > Each individual monitor may have a different subpixel arrangement (chiefly > due to users wanting one in portrait while another is in landscape). > > Though I think Wayland will ignore all this initially, it should provide an > API so this can be done in the future. Something like this: > > 1. When a client provides an image, it also tells the compositor what > subpixel arrangement it was rendered for (none, horizontal and vertical rgb > or bgr, etc). The compositor can use this information to change how > filtering is done in transforms. > > 2. The compositor informs the client about the arrangement of all the > monitors, and part of this is the subpixel arrangement of each of them. The > client can then render images with the correct subpixel for the monitor. It > can assume that if the scale is 1:1 and the subpixels match, that the > compositor will put those pixels unchanged on the monitor. > > 3. To allow "perfect" output when a window spans monitors with different > subpixel arrangements, I think the easiest way would be for clients to be > able to restrict an image to particular monitors. The client could then > provide two source images, each drawn for a given monitor and restricted to > it, and each with the same transform. The user would see the window spanning > the two monitors, but as they moved the window, if they look really closely, > would see the antialiasing switch between them. > > ___ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jon Smirl [email protected] ___ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HPC (High Performance Compute) Architecture
On Thu, Mar 17, 2011 at 6:52 AM, Josh Leverette wrote: > (And I have been known to get overexcited about ideas sometimes, which may > cause an idea to go from cool to killer) A couple of years ago there was a startup doing exactly this for video games. They would buy video games and let you play them remotely on their servers. The game displays were converted into real-time video streams. You paid by the hour. I've lost track of the company and can't remember its name. You can do this in any OS, it does not need Wayland support. All of these remoting technologies are focused on providing network transparent access to legacy apps. Since this is the world of open source, another strategy is to simply alter those legacy apps to use a network transparent UI like HTML5. If OpenOffice were converted to HTML5 you could still run it standalone by running both the client and sever pieces on the same machine. > > Sincerely, > Josh > > On Mar 17, 2011, at 6:49 AM, Josh Leverette wrote: > >> Ah, ok, it's good to hear something remotely (no pun intended) similar is in >> the works. And I don't predict lion taking over by any means, just being the >> best for a little while, even if expensive, and that windows hasn't been >> feature competitive with Linux in at least a couple of years in my opinion. >> >> Sincerely, >> Josh >> >> On Mar 16, 2011, at 11:54 PM, Marty Jack wrote: >> >>> Mostly, it is identically equal to "remote Wayland protocol". Except that >>> this iSwifter thing is specific to remoting Flash applications. >>> >>> Speaking of which there is a GSOC'11 proposal over on X.org to do the >>> remote Wayland protocol. >>> >>> The parts about Lion taking over the world I am skeptical of seeing that to >>> my knowledge Lion is only going to run on hardware supplied by Apple, which >>> is a tiny fraction of all hardware. >>> >>> But, don't let me dissuade anyone, it is open source and people should feel >>> free to work on anything they think is valuable. >>> >>> On 03/16/2011 10:53 PM, Corbin Simpson wrote: >>>> Um. >>>> >>>> This sounds overly grandiose and not really Wayland-specific. Also, most >>>> people don't have lots of iron sitting in their garages. I think you may >>>> have upgraded "Wouldn't it be cool if...?" to "Dude, this is a killer >>>> feature!" >>>> >>>> Sending from a mobile, pardon the brevity. ~ C. >>>> >>>> On Mar 16, 2011 7:11 PM, "Josh Leverette" >>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> ___ >>>> wayland-devel mailing list >>>> [email protected] >>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >>> ___ >>> wayland-devel mailing list >>> [email protected] >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jon Smirl [email protected] ___ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
