Re: client side decorations
* microcai micro...@fedoraproject.org schrieb: When app lock up, the wayland can start a remote-thread inside the client, and this thread can handle move/drag stuff or even terminate the process. This can be implemented as a signal hander inside libwayland-client, or no need to start the thread at-all. Wow, what a reliable proposal. Server relies on client not doing bad things. When the client locks up, it's normally far too late to do anything useful there ... So the libwayland-client must juse one signal internally. But there is no problem here. GUI app usually don't use signals. Really ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: What's wrong with wayland?
* Sam Spilsbury smspil...@gmail.com schrieb: It really isn't that complicated. Just make a Netland server which manages your application's buffer and transmits it across the network to the other Netland server which then fills the buffer on the client machine. A buffer of what exactly ? Framebuffer ? The whole reason remoting was taken out at the server level is because these days it accounts for a lot of the overhead you'll get with rendering, True for X11, but not neccessarily for a completely new approach. since the majority of clients will do all the surface painting Client-side (cairo, Qt) or direct to the hardware (OpenGL). That's the main problem, IMHO. It leads to really a lot of unnecessary code and data duplication. (btw: I'm glad to have all my systems free of the Qt bloat ;-o). Alternative: let the clients just _describe_ their window contents as vector graphics, that only get manipulated when needed (and NOT repainted over and over by the client itself!). Most of the common widget toolkit's code (and runtime data) would be simply obsolete this way. The other reason why remoting at a server level has become more useless is because people *are* choosing to use client-side rendering libraries like cairo and Qt and just sending the bitmaps to the X Server. Because X (which just happens to be the current standard) doesn't provide high level functionality required todays. Doing this on client-side is just a ugly workaround on a limited protocol. In a network situation this drastically increases bandwidth usage, rather than the relatively small bandwidth operations such as lines, arcs and fills. So what we have now for networking is this sub-optimal mix of both round-tripping a lot when we don't need to (latency) /and/ high-bandwidth usage. Wayland doesn't even have anything like a network situation ... 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. This is indeed the kind of remoting that could be achieved at a toolkit level. Yes, but it still leaves the big bandwith/latency problems, most notably the need for client-side repainting still in place. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: What's wrong with wayland?
* Marty Jack marty...@comcast.net 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). 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: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: What's wrong with wayland?
* Sam Spilsbury smspil...@gmail.com schrieb: But the core part of X11 is that it only managed windows and pixmaps which were owned by clients running in different processes over a network protocol. The window manager and compositors are implemented externally, using that information from the server to blit the graphics on to the screen and actually change the size and position of the windows. ACK. And that is a very strong concept. It allows one to eg. choose window manager on the fly and even run it on a different host. Very handy for distributed environments. I, personally, definitively don't want to loose that, similarily as I also never want to loose the ability to run individual clients on separate hosts easily. The key difference with wayland is two-fold. First of all, it recognizes that server-side rendering is a bit useless and Why exactly is that useless ? Do you want all remote clients to transfer huge bitmaps for every little change on screen ? Or do you want no remote clients at all ? Second of all, it integrates the windowmanager, compositing manager and window server into one process(through libwayland-compositor). That's the point that annoys me: I want the window manager to remain separate and exchangable at runtime. Wayland requires that you render to a graphics buffer on the hardware (eg direct to memory that is accessible to the video card). So, no chance for distribution between several hosts, virtualization, etc. At this point, I'm really curious about what makes it so different from or better than Fusion ? It is also likely that any other drawing frameworks are going to be implemented on top of OpenGL ES since that is the most portable way of implementing a draw-to-buffer method. What about graphics devices that don't support it ? Software rendering ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
* Chris Morgan chmor...@gmail.com schrieb: Maybe we could compile the c code as c++? Wouldn't require using classes etc but would provide better type conversion checking. Actually, I'm currently in process of building several packages with an C++ (instead of C) compiler for analysis and cleanup purposes (eg. it enforced you to write parameter types before the parameter names, and other things I'd consider much cleaner). This approach might turn out as a fine QM tool ... cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Some of my thoughts on input for wayland
* Chase Douglas chase.doug...@canonical.com schrieb: Can you describe more here? If you are meaning a real computer process, I think it would help to split input and output display into separate processes. Practically every system shipping in the future will have multiple cores, so making the input system wait around while output does its thing seems unnecessary. Of course, processes are the natural way of parallelism (on mainline architectures). But we'll have to differenciate between separate layers of input events. Things like transforming lolevel scancodes into some highlevel keystrokes (eg. mapping the scancode for 'A' to some key A was pressed event or decoding mouse protocol into movement events) probably would find a good place in separate server processes (eg. little 9P servers, and their clients capable of dynamically reconnecting, so the servers can be plugged easily). But at the windowing layer - transforming an global mouse click into an click event _within_ some window - we need the window geometries, so that should live in a process which knows about all of this. (this doesn't necessarily doesn't need the actual _display_ server, but the one who actually handles window positioning/sizing). cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
