Re: Wayland Window Management Proposal
On 11 May 2011 20:25, Bill Spitzak spit...@gmail.com wrote: Michal Suchanek wrote: Moves and resizes implemented in the client can't work well. Any resize solution that does not allow an atomic on-screen update of a window to it's new size, with the resized decorations and contents, is unacceptable. The whole point of Wayland is that the user NEVER sees a partially-updated window. It is therefore impossible to finish a resize without waiting for the client to update the window contents. Since you have to wait for that, there is no reason the client can't also draw the decorations. I'm sorry if this makes writing clients harder. Deal with it. Always waiting for the client is something that cannot be upheld. There are situations when - the client is busy or stuck - the client is swapped out or a low priority process - the client is remote and therefore resizing it will take some time whatever you do If Wayland can't deal with any of the above it's junk. The window management functions should be working without lag so long as the window manager and Wayland server have enough resources and high enough priority. You can't expect that every single client is high-priority and lag-free. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
microcai wrote: They can't care how big a windows is in the pixel, but in the inch. People should have different monitors with different DPI. Windows should stay same size regardless the DPI. Force DPI==96 on every monitor is a stupid idea, and we should avoid it on the protocol side. The reason this had to be done was due to the incredibly stupid idea that only *fonts* are measured in points, and every other graphic is measured in pixels. This strange idea was on both X and Windows, likely due to the initial programs being terminal emulators where there was no graphics other than text. What this really means is that there are two different coordinate systems for all the graphics, and programmers just assumed these two systems always lined up exactly like they did on their screen. After a lot of awful looking output on screens with different DPI, both Windows and then X resorted to just forcing the DPI to 96, thus making the systems obey the programmer's assumptions. Bad DPI settings are still a bug on X, producing ridiculous large and tiny font sizes unexpectedly, and this is NEVER wanted. The correct solution would have been to specify all coordinates in the same units, likely 1 unit in the CTM. For practical reasons on current-day screens this wants to be a pixel by default, but there is no reason a program can't read the DPI and set the CTM to draw actual-size graphics. I suggest, DPI should also be windows specific, so that compositor can *scale it*. If I understand it right, a Wayland window has both a rectangle measured in screen coordinates, and a source image that can be a different size. The compositor is expected to transform the source image (scale it) to fit in the rectangle. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
On 12 May 2011 19:47, Bill Spitzak spit...@gmail.com wrote: microcai wrote: They can't care how big a windows is in the pixel, but in the inch. People should have different monitors with different DPI. Windows should stay same size regardless the DPI. Force DPI==96 on every monitor is a stupid idea, and we should avoid it on the protocol side. The reason this had to be done was due to the incredibly stupid idea that only *fonts* are measured in points, and every other graphic is measured in pixels. This strange idea was on both X and Windows, likely due to the initial programs being terminal emulators where there was no graphics other than text. What this really means is that there are two different coordinate systems for all the graphics, and programmers just assumed these two systems always lined up exactly like they did on their screen. After a lot of awful looking output on screens with different DPI, both That's not really true. Of course, there are things that look awful in different DPI (or because you happen to have slightly different fonts than the author) because they were done by braindead people. This includes but is not limited to - many web sites - (some?) Adobe and HP software - OS X (which actually prevents changing the DPI in the first place leaving you with ridiculous font sizes) Note that very first UIs were virtually bitmap-free and all the WM buttons and borders were vector graphics or generated on the spot from a few user-specified parameters (Windows 3.1, old stuff like mwm, olwm, fvwm, ..) and could be scaled to any size you specified. Then bitmaps were used heavily and made their way to stuff like window borders because the level of complexity people desired for their eye-candy could not be done with simple vector graphics anymore, and complex vector graphics required more power than people were willing to sacrifice for window borders. Still GTK bitmap themes have provisions for scaling the bitmaps to suit any text sizes in window captions and buttons. The button border will be relatively thinner to the text size (or thicker for smaller text) but will still render as intended, and people are free to choose a different theme. Similarly in Windows you can set different border sizes or font sizes if you accept that tons of braindead software breaks (eg. Adobe CS or HP scanner dialogs). Also Windows bitmapped window buttons look terribly on non-default sized borders but vector buttons are still available. The web is a problem because due to the specs being how they are they are not really friendly to people conscious about the look of their sites and many effects can't be achieved in a portable way without setting the element sizes exactly in pixels. You can say it's a defect in the specs or an error on the side of the people who are trying to stretch them to make their sites look flashy at the expense of usability but it's totally offtopic here. Windows and then X resorted to just forcing the DPI to 96, thus making the systems obey the programmer's assumptions. Bad DPI settings are still a bug on X, producing ridiculous large and tiny font sizes unexpectedly, and this is NEVER wanted. The correct solution would have been to specify all coordinates in the same units, likely 1 unit in the CTM. For practical reasons on current-day screens this wants to be a pixel by default, but there is no reason a program can't read the DPI and set the CTM to draw actual-size graphics. Well, they can't on systems where DPI is always forced to be 96 regardless of the actual screen physical properties. Also this is reportedly[1] done so that people don't get ridiculously small text on TVs but it is at the expense of getting ridiculously small DPI on most netbooks and high-end notebooks so this is not really a good tradeoff IMHO. Thanks Michal [1] https://bugs.freedesktop.org/show_bug.cgi?id=23705 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
OpenGL support in EGL 1.4
Considering the changes made in the latest version of EGL, released on April 6, I'd like to point out that OpenGL-proper is now one of the official EGL client APIs. Revisions to the FAQ, anyone? http://www.khronos.org/registry/egl/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
mccrocai wrote: That's not true. DPI is not only used by font size, but also by image size and ther things You don't want you 300DPI screen display *tiny tiny font*, will you? By designing the protocol *DPI aware*, and force the application deal with the DPI natively, we get better user experience. I think I didn't explain the problem right. I agree that it would be nice if programs were DPI-aware. The problem is that the idiots doing both X and windows built in DPI-awareness to only *PART* of the graphics api. Font sizes were chosen in points. EVERY OTHER GRAPHIC was measured in pixels. A graphics api where everything is measured in points (ie paying attention to the DPI) would make sense. One where everything is measured in pixels would also make sense. But this combination is a stupid idea and we are paying for it today with the inability to scale graphics. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: OpenGL support in EGL 1.4
I see no changes regarding client API's in the updated EGL spec. OpenGL was already an offical Client API before, and indeed we're using that for the wayland-demos clients, since cairo supported only opengl, not gles2, until recently. The FAQ doesnt need to be updated, nothing in there says OpenGL is not used because of EGL. It says because of GLX symbols, which are avoided in the compositor by using gles2. 2011/5/12 Mak Nazečić-Andrlon owlberteinst...@gmail.com: Considering the changes made in the latest version of EGL, released on April 6, I'd like to point out that OpenGL-proper is now one of the official EGL client APIs. Revisions to the FAQ, anyone? http://www.khronos.org/registry/egl/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
