* [9fans] suggestion : new service targets for plan9 @ 2022-01-28 2:03 ibrahim via 9fans 2022-01-28 5:22 ` ori ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: ibrahim via 9fans @ 2022-01-28 2:03 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 2656 bytes --] I developed a kiosk version of plan9 (based on 9front and legacy9) and am about to develop a single user desktop system. Those can coexist with the existing plan9 system. I named the new service targets kiosk and desktop. Both work without rio. Currently I used initdraw, initmouse, initkeyboard, loadimage, flushimage from devdraw to avoid breaking of compatibility with the existing plan9 systems while the whole rendering of the windows is framebuffer based. Instead of the usual plan9 fonts I used regular truetypefonts. So my suggestions would be : 1) Define new service targets kiosk and desktop (Currently I do this in init or /user/.../lib/profile. This makes it possible for a user to start an alternative window manager or even a single applicaton (kiosk service) with a modern look and feel. 2) Define a layer between vga and devdraw perhaps vgafb which improves the performance for frame buffer rendered window managers. 3) Define events for mouse, keyboard, touchpad, windows which is based on notes managed by light threads inside the client app. Those three steps would protect the existing plan9 from changes and make it possible to only use the kernel, libraries, tools from alternative user interfaces. Plan9 is one of the smallest operating systems accompanied with a compiler and an abstraction which would attract much more developers and users if it had a modern user interface. We don't have to throw away anything and rio would even be able to run inside a window of a modern desktop. Plan9 has everything necessary to make it an attractive system not only for a handful of developers. The compilers, the portability, 9p, unicode, direct support for video hardware and its small size are fascinating. The only reason why it isn't recognized by more people is its GUI. I don't get the reason why we wouldn't extent it so we can use other GUI's while keeping the existing in respect of the developers who created this system. I will integrate this changes but I would prefer staying fully compatible to the existing projects legacy9 and 9front even more I would prefer not forking any of them but sharing my parts as contributions. What I need and what those changes need is a separation level between devdraw and the graphics hardware and a new event mechanism which can be based on notes or equals. I'm not a native English speaker so excuse the many mistakes. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mb4eb2005f779e611cdef4de4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 3549 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] suggestion : new service targets for plan9 2022-01-28 2:03 [9fans] suggestion : new service targets for plan9 ibrahim via 9fans @ 2022-01-28 5:22 ` ori 2022-01-28 11:38 ` ibrahim via 9fans 2022-01-28 7:50 ` vic.thacker 2022-01-28 9:55 ` Frank D. Engel, Jr. 2 siblings, 1 reply; 12+ messages in thread From: ori @ 2022-01-28 5:22 UTC (permalink / raw) To: 9fans Quoth ibrahim via 9fans <9fans@9fans.net>: > 1) Define new service targets kiosk and desktop > (Currently I do this in init or /user/.../lib/profile. > This makes it possible for a user to start an > alternative window manager or even a single applicaton > (kiosk service) with a modern look and feel. It'd probably make sense to generalize: 'service=foo' in plan9.ini could run /bin/^$foo^rc. > 2) Define a layer between vga and devdraw perhaps > vgafb which improves the performance for frame > buffer rendered window managers. Why would another layer be help? Libmemdraw is not very fast, and profiling+optimization will be needed to solve that, but I'm not sure what an additional layer is supposed to do there. > 3) Define events for mouse, keyboard, touchpad, > windows which is based on notes managed by light > threads inside the client app. Sure. It fits -- same place as kbdfs -- but someone needs to come up with the event encoding, write the 'touchfs', and implement the readers that toss events down channels. Nothing insurmountable, just needs someone who cares about it to roll up their sleeves and write code. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M90f04064296185341f04b17f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] suggestion : new service targets for plan9 2022-01-28 5:22 ` ori @ 2022-01-28 11:38 ` ibrahim via 9fans 0 siblings, 0 replies; 12+ messages in thread From: ibrahim via 9fans @ 2022-01-28 11:38 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 4075 bytes --] On Friday, 28 January 2022, at 6:22 AM, ori wrote: > It'd probably make sense to generalize: 'service=foo' in plan9.ini could run /bin/^$foo^rc. This is an excerpt for one experimental gdi from profile ... ramfs font = /lib/font/bit/lucida/unicode.10.font upas/fs fn cd { builtin cd $* && awd } # for acme service=kiosk case kiosk echo -n accelerated > '#m/mousectl' echo -n 'res 3' > '#m/mousectl' prompt=('term% ' ' ') fn term%{ $* } # cat /sys/lib/kbmap/de > /dev/kbmap exec /usr/glenda/proj/gdi/gdi # exec rio -f /lib/font/bit/lucida/unicode.10.font case terminal plumber echo -n accelerated > '#m/mousectl' echo -n 'res 3' > '#m/mousectl' prompt=('term% ' ' ') fn term%{ $* } exec rio -f /lib/font/bit/lucida/unicode.10.font # exec /usr/glenda/proj/gdi/gdi ... I defined kiosk as a service target inside profile and by editing profile before starting I can switch between the new window system and rio both can run inside each other. By defining well known targets like kiosk or desktop aso the compilation would get easier and due to the existing environment variable the running main window system would be known to client apps (even if not necessary)On Friday, 28 January 2022, at 6:22 AM, ori wrote: > Why would another layer be help? Libmemdraw is not very fast, and profiling+optimization will be needed to solve that, but I'm not sure what an additional layer is supposed to do there. The extra layer would make sharing of the optimized framebuffer device usable for both window managers directly using this fbdev and also for devdraw (memlayer, memdraw). In last instance devdraw does also render to the graphics memory so this layer would be shared by both. This extra layer would make sure that only one application has direct access to the framebuffer while the other gets multiplexed. I did the multiplexing in my window manager for rio so its possible to run my window manager inside rio and vice versa. The alternative would be a parallel fbdev with the risk that both devdraw as well as this dev driver try to write concurently to the video memory. The changes to memlayer memdraw devdraw would be minimalistic but are not really necessary. Those changes would make both window systems benefit by a shared code base and improvements in this code base while totally transparent for any application running on the system. On Friday, 28 January 2022, at 6:22 AM, ori wrote: > Sure. It fits -- same place as kbdfs -- but someone needs to come up with the event encoding, write the 'touchfs', and implement the readers that toss events down channels. Nothing insurmountable, just needs someone who cares about it to roll up their sleeves and write code. if(initdraw(nil, nil, argv0) < 0) sysfatal("%s: %r", argv0); if((mctl = initmouse(nil, screen)) == nil) sysfatal("%s: %r", argv0); if((kctl = initkeyboard(nil)) == nil) sysfatal("%s: %r", argv0); pixi_init() ; test_fb () ; draw_fb () ; enum{MOUSE, RESIZE, KEYBD, NONE}; Alt alts[4] = { {mctl->c, &mouse, CHANRCV}, {mctl->resizec, &resize, CHANRCV}, {kctl->c, &r, CHANRCV}, {nil, nil, CHANEND}, }; Currently I'm doing things for event handling like in a rio app and it works but the code could be simplified by a notification layer which we can define all together. To make things more clear : I have a working kiosk and an experimental window system but those can be improved and I would prefer making those things a general well documented part of the system. The more people experiment with such an enhancement the more it evolves and the less bugs will remain. I have ideas and I'm sure others also have ideas so it would be best to share opinions and learn from each other. I don't like forking a project when I like its progress as I do regarding 9front legacy9. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M5b9c63bb91f21f3264e973ff Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 5710 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] suggestion : new service targets for plan9 2022-01-28 2:03 [9fans] suggestion : new service targets for plan9 ibrahim via 9fans 2022-01-28 5:22 ` ori @ 2022-01-28 7:50 ` vic.thacker 2022-01-28 11:49 ` ibrahim via 9fans 2022-01-28 9:55 ` Frank D. Engel, Jr. 2 siblings, 1 reply; 12+ messages in thread From: vic.thacker @ 2022-01-28 7:50 UTC (permalink / raw) To: leimy2k via 9fans On Fri, Jan 28, 2022, at 11:03, ibrahim via 9fans wrote: > I developed a kiosk version of plan9 (based on 9front and legacy9) and > am about to develop a single user desktop system. Those can coexist > with the existing plan9 system. > > I named the new service targets kiosk and desktop. Both work without rio. [snip] Hmm. Have you considered using Inferno? - Vic ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M540668e32b072efd37d6f13e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] suggestion : new service targets for plan9 2022-01-28 7:50 ` vic.thacker @ 2022-01-28 11:49 ` ibrahim via 9fans 0 siblings, 0 replies; 12+ messages in thread From: ibrahim via 9fans @ 2022-01-28 11:49 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 1105 bytes --] On Friday, 28 January 2022, at 8:53 AM, vic.thacker wrote: > Hmm. Have you considered using Inferno? I gave it a try long ago but I don't want to use it. The reason is the involvement of limbo. I prefer system code to be written in a language that I'm using now for decades and where I can change even the compiler for my needs. I wouldn't use the first releases of plan9 either due to the same reason (alef). Another reason why I prefer legacy9 or 9front is the evolving codebase. Both projects are active and the more people share the code the more bugs get explored. The ideas behind inferno are compatible to mine but I prefer an active project as the shared basement for enhancements of a system. But thanks for this hint, cause my suggestions are already integrated in inferno and if I would only need an existing solution using inferno would make sense. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mc26a105eafd97f19f62fbcc0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 1785 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] suggestion : new service targets for plan9 2022-01-28 2:03 [9fans] suggestion : new service targets for plan9 ibrahim via 9fans 2022-01-28 5:22 ` ori 2022-01-28 7:50 ` vic.thacker @ 2022-01-28 9:55 ` Frank D. Engel, Jr. 2022-01-28 12:13 ` sirjofri 2022-01-28 12:21 ` ibrahim via 9fans 2 siblings, 2 replies; 12+ messages in thread From: Frank D. Engel, Jr. @ 2022-01-28 9:55 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 5627 bytes --] I was actually thinking of a somewhat different approach to providing a more modernized user interface. Consider that rio currently exports the required files for each window, which provide the same interface as the display driver underneath them. Now consider adding a new "control manager" file server which exports a filesystem to manage individual controls arranged inside a window (or at the root level if not running rio or other window manager). Create a directory inside the exported filesystem to add a new control. Inside the directory would automatically appear those same files that are exported by rio or by vga, but specific to the control. There would also be a file for controlling the scaling and placement of child controls of the control in some defined manner, allowing "layout managers" to be defined (such a file would also appear at the root). Add a new subdirectory within the directory of a control to create a child control. Individual types of controls can then be implemented as separate programs or libraries which would interact with those basic elements to provide the specific functionality of a control or layout manager - standard controls to be provided would be the typical buttons, checkboxes, text fields, etc., while layout managers would arrange their children in specific patterns, such as vertically stacked, horizontally stacked, grids, etc. This mechanism is an extensible way to cover the provision of "modern" controls within a window, even when still using rio, and is true to the "everything is a filesystem" nature of plan9. A second step would be to create an alternative to rio which would do the same job, but with title bars and the like. Some kind of file management / desktop environment application could then be built on top of these foundations. Users could mix and match the use of applications based on the control manager within the existing rio environment, and the existing command line / rio applications such as acme would work unmodified with the new window manager but have "modern" title bars and some sort of "minimize" and possibly "full screen" functionality, maybe with a dock of some kind. As far as I can tell this would require practically zero core changes to the system as it is built entirely on existing primitives already offered. On 1/27/22 9:03 PM, ibrahim via 9fans wrote: > I developed a kiosk version of plan9 (based on 9front and legacy9) and > am about to develop a single user desktop system. Those can coexist > with the existing plan9 system. > > I named the new service targets kiosk and desktop. Both work without rio. > > Currently I used initdraw, initmouse, initkeyboard, loadimage, > flushimage from devdraw to avoid breaking of compatibility with the > existing plan9 systems while the whole rendering of the windows is > framebuffer based. Instead of the usual plan9 fonts I used regular > truetypefonts. > > So my suggestions would be : > > 1) Define new service targets kiosk and desktop (Currently I do this > in init or /user/.../lib/profile. This makes it possible for a user to > start an alternative window manager or even a single applicaton (kiosk > service) with a modern look and feel. > > 2) Define a layer between vga and devdraw perhaps vgafb which improves > the performance for frame buffer rendered window managers. > > 3) Define events for mouse, keyboard, touchpad, windows which is based > on notes managed by light threads inside the client app. > > Those three steps would protect the existing plan9 from changes and > make it possible to only use the kernel, libraries, tools from > alternative user interfaces. Plan9 is one of the smallest operating > systems accompanied with a compiler and an abstraction which would > attract much more developers and users if it had a modern user > interface. We don't have to throw away anything and rio would even be > able to run inside a window of a modern desktop. > > Plan9 has everything necessary to make it an attractive system not > only for a handful of developers. The compilers, the portability, 9p, > unicode, direct support for video hardware and its small size are > fascinating. > > The only reason why it isn't recognized by more people is its GUI. I > don't get the reason why we wouldn't extent it so we can use other > GUI's while keeping the existing in respect of the developers who > created this system. > > I will integrate this changes but I would prefer staying fully > compatible to the existing projects legacy9 and 9front even more I > would prefer not forking any of them but sharing my parts as > contributions. > > What I need and what those changes need is a separation level between > devdraw and the graphics hardware and a new event mechanism which can > be based on notes or equals. > > I'm not a native English speaker so excuse the many mistakes. > > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mb4eb2005f779e611cdef4de4> > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M54ac272859201587addb6b91 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 6903 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] suggestion : new service targets for plan9 2022-01-28 9:55 ` Frank D. Engel, Jr. @ 2022-01-28 12:13 ` sirjofri 2022-01-28 12:21 ` ibrahim via 9fans 1 sibling, 0 replies; 12+ messages in thread From: sirjofri @ 2022-01-28 12:13 UTC (permalink / raw) To: 9fans Hey, that was my idea! 😉 Well, to be precise, I also had the idea of having a filesystem hierarchy for window contents. /mnt/window/mywindow/vbox/hbox/button/label/ and inside that: text, padding, margin, ... Whatever you like. It would be easy to write UIs using shell scripts, and to be fair, many user applications can just be a shell script that hauls data between UI and specialized filesystems for their task. I suggest you look at the rcgui test I did quite some time ago, I believe it's available at https://git.sr.ht/~sirjofri/rcgui. It's sadly not a filesystem, but does an app lifecycle approach and you can react to events like redraw and give simple text draw commands for button controls. I really would like to see the filesystem approach as that's what my goal is, but I was not so good at implementing filesystems (although I have many ideas) and I have very limited time due to ninephone project and especially work. Btw I was planning to have some kinda filesystem wrapper so you can easily write simple filesystems using rc, some kinda glorified 9pcon, but that's another topic. if you're interested in discussing touch UI ideas (or stuff that leads towards touch UI on 9) I set up a garden repository on shithub for this exact purpose. garden means, you only need a shithub account and have push access. The URL is http://shithub.us/garden/touchui/HEAD/info.html . I wanted to add my ideas earlier, but I sadly didn't have enough time for that (I have ideas though, just need to write them down). sirjofri 28.01.2022 10:55:01 Frank D. Engel, Jr. <fde101@fjrhome.net>: > I was actually thinking of a somewhat different approach to providing a > more modernized user interface. > > Consider that rio currently exports the required files for each window, > which provide the same interface as the display driver underneath them. > > Now consider adding a new "control manager" file server which exports a > filesystem to manage individual controls arranged inside a window (or > at the root level if not running rio or other window manager). Create > a directory inside the exported filesystem to add a new control. > Inside the directory would automatically appear those same files that > are exported by rio or by vga, but specific to the control. There > would also be a file for controlling the scaling and placement of child > controls of the control in some defined manner, allowing "layout > managers" to be defined (such a file would also appear at the root). > Add a new subdirectory within the directory of a control to create a > child control. > > Individual types of controls can then be implemented as separate > programs or libraries which would interact with those basic elements to > provide the specific functionality of a control or layout manager - > standard controls to be provided would be the typical buttons, > checkboxes, text fields, etc., while layout managers would arrange > their children in specific patterns, such as vertically stacked, > horizontally stacked, grids, etc. > > This mechanism is an extensible way to cover the provision of "modern" > controls within a window, even when still using rio, and is true to the > "everything is a filesystem" nature of plan9. > > > A second step would be to create an alternative to rio which would do > the same job, but with title bars and the like. > > > Some kind of file management / desktop environment application could > then be built on top of these foundations. Users could mix and match > the use of applications based on the control manager within the > existing rio environment, and the existing command line / rio > applications such as acme would work unmodified with the new window > manager but have "modern" title bars and some sort of "minimize" and > possibly "full screen" functionality, maybe with a dock of some kind. > > > As far as I can tell this would require practically zero core changes > to the system as it is built entirely on existing primitives already > offered. > > > On 1/27/22 9:03 PM, ibrahim via 9fans wrote: > I developed a kiosk version of plan9 (based on 9front and legacy9) and > am about to develop a single user desktop system. Those can coexist > with the existing plan9 system. > > I named the new service targets kiosk and desktop. Both work without > rio. > > Currently I used initdraw, initmouse, initkeyboard, loadimage, > flushimage from devdraw to avoid breaking of compatibility with the > existing plan9 systems while the whole rendering of the windows is > framebuffer based. Instead of the usual plan9 fonts I used regular > truetypefonts. > > So my suggestions would be : > > 1) Define new service targets kiosk and desktop (Currently I do this in > init or /user/.../lib/profile. This makes it possible for a user to > start an alternative window manager or even a single applicaton (kiosk > service) with a modern look and feel. > > 2) Define a layer between vga and devdraw perhaps vgafb which improves > the performance for frame buffer rendered window managers. > > 3) Define events for mouse, keyboard, touchpad, windows which is based > on notes managed by light threads inside the client app. > > Those three steps would protect the existing plan9 from changes and > make it possible to only use the kernel, libraries, tools from > alternative user interfaces. Plan9 is one of the smallest operating > systems accompanied with a compiler and an abstraction which would > attract much more developers and users if it had a modern user > interface. We don't have to throw away anything and rio would even be > able to run inside a window of a modern desktop. > > Plan9 has everything necessary to make it an attractive system not only > for a handful of developers. The compilers, the portability, 9p, > unicode, direct support for video hardware and its small size are > fascinating. > > The only reason why it isn't recognized by more people is its GUI. I > don't get the reason why we wouldn't extent it so we can use other > GUI's while keeping the existing in respect of the developers who > created this system. > > I will integrate this changes but I would prefer staying fully > compatible to the existing projects legacy9 and 9front even more I > would prefer not forking any of them but sharing my parts as > contributions. > > What I need and what those changes need is a separation level between > devdraw and the graphics hardware and a new event mechanism which can > be based on notes or equals. > > I'm not a native English speaker so excuse the many mistakes. > > > *9fans[https://9fans.topicbox.com/latest]* / 9fans / see > discussions[https://9fans.topicbox.com/groups/9fans] + > participants[https://9fans.topicbox.com/groups/9fans/members] + > delivery options[https://9fans.topicbox.com/groups/9fans/subscription] > Permalink[https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M54ac272859201587addb6b91] ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M9e7cea6cac0af336bf4dd3ac Delivery options: https://9fans.topicbox.com/groups/9fans/subscription ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] suggestion : new service targets for plan9 2022-01-28 9:55 ` Frank D. Engel, Jr. 2022-01-28 12:13 ` sirjofri @ 2022-01-28 12:21 ` ibrahim via 9fans 2022-01-28 14:11 ` Philip Silva via 9fans 2022-01-28 15:49 ` ori 1 sibling, 2 replies; 12+ messages in thread From: ibrahim via 9fans @ 2022-01-28 12:21 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 1477 bytes --] On Friday, 28 January 2022, at 10:55 AM, Frank D. Engel, Jr. wrote: > As far as I can tell this would require practically zero core changes to the system as it is built entirely on existing primitives already offered. What you are suggesting is a higher level filesystem and libdraw combined with the panel library is implemented in a comparable way. This results in decrease of performance. Because the renderer has to read all the files for all visible regions on the screen and combine them for the display image. memdraw and memlayer which are used by devdraw are doing a similar job they combine image memory layers to form the resulting display image. What I suggest is a lower level interface to use the framebuffer directly and I think devdraw (memdraw, memlayer) is too high level and rio oriented. If you use devdraw as a framebuffer than the only functions you need from devdraw are initdraw, loadimage and flushimage which internally use memdraw and memlayer in a way that decreases performance. Also the transfer of images in this way is expensive (regarding time) a screen image is at least copied two times. So by defining a lower level we could improve the performance of rendering by a factor of two. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Meea8f954e2d142447d743e3f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 2114 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] suggestion : new service targets for plan9 2022-01-28 12:21 ` ibrahim via 9fans @ 2022-01-28 14:11 ` Philip Silva via 9fans 2022-01-28 15:27 ` ibrahim via 9fans 2022-01-28 15:49 ` ori 1 sibling, 1 reply; 12+ messages in thread From: Philip Silva via 9fans @ 2022-01-28 14:11 UTC (permalink / raw) To: 9fans Also of course it depends on what needs to be rendered. I didn't deep-dive yet into the internals of it, but isn't it that when combining the images at the end, that transfer of the initial images with lots of data basically happens only once? It seems to me devdraw can be quite performant on certain use cases. (UIs with basic shapes) But true, having access to the framebuffer should offer more options. Also I wonder what kind of functions it should be providing. (And if devdraw couldn't be just made faster) > What I suggest is a lower level interface to use the framebuffer directly and I think devdraw (memdraw, memlayer) is too high level and rio oriented. ... Also the transfer of images in this way is expensive (regarding time) a screen image is at least copied two times. So by defining a lower level we could improve the performance of rendering by a factor of two. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M3f8fff74c67b09c5e2cde53f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] suggestion : new service targets for plan9 2022-01-28 14:11 ` Philip Silva via 9fans @ 2022-01-28 15:27 ` ibrahim via 9fans 2022-01-28 15:44 ` ibrahim via 9fans 0 siblings, 1 reply; 12+ messages in thread From: ibrahim via 9fans @ 2022-01-28 15:27 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 1994 bytes --] On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote: > I didn't deep-dive yet into the internals of it, but isn't it that when combining the images at the end, that transfer of the initial images with lots of data basically happens only once? It seems to me devdraw can be quite performant on certain use cases. (UIs with basic shapes) Thats true. devdraw prepares its images using memdraw and memlayer. After combining those images we get the results on the display. The moment you do rendering inside your application you have to transfer images using loadimage and flashimage. There is no message inside devdraw which makes it possible to use images from a client process without copying them into the memlayer infrastructure. On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote: > Also I wonder what kind of functions it should be providing. This intermediate or alternative layer should only add putimage switchbuffers supported by shared memory segments. At least there should be two buffers one foreground and one background buffer directly writeable by the client. One simple way to realize this would be enhancing devdraw with one single protocol which would render a client side image from shared memory (segments). You can quite now create memimages but if you realize the rendering you have to use loadimage and flushimage each time your images change. devdraw is not slow but it can be made faster with only one extra protocol which is missing. Enhancing devdraw this way would also solve the problem but not touching devdraw and offering an intermediate level between the graphics driver and devdraw wouldn't break anything. In the end devdraw also transfers its image to the videocard one way or the other. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mbe750adf3a20ec4a7f7c7b5d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 2833 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] suggestion : new service targets for plan9 2022-01-28 15:27 ` ibrahim via 9fans @ 2022-01-28 15:44 ` ibrahim via 9fans 0 siblings, 0 replies; 12+ messages in thread From: ibrahim via 9fans @ 2022-01-28 15:44 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 796 bytes --] A well established example for direct rendered frame support is the SHM extension of X11. There you can create a shared memory in your application and render directly into this. Afterwards you switch buffers without any transfer of image data. The image is directly rendered on the screen if the application and the display rest on the same computer. In X11 this results in a great performance gain cause you don't have to invoke X11 for each drawing primitive and you don't have to transfer the image data when the image is ready. libSDL uses a similar approach. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Me6991ab04cfbfa8bef2b4f2c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 1343 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] suggestion : new service targets for plan9 2022-01-28 12:21 ` ibrahim via 9fans 2022-01-28 14:11 ` Philip Silva via 9fans @ 2022-01-28 15:49 ` ori 1 sibling, 0 replies; 12+ messages in thread From: ori @ 2022-01-28 15:49 UTC (permalink / raw) To: 9fans Quoth ibrahim via 9fans <9fans@9fans.net>: > What I suggest is a lower level interface to use the framebuffer > directly and I think devdraw (memdraw, memlayer) is too high level and > rio oriented. I don't think this is desirable. Every single program uses devdraw directly. Rio is just another devdraw client. > If you use devdraw as a framebuffer than the only > functions you need from devdraw are initdraw, loadimage and flushimage > which internally use memdraw and memlayer in a way that decreases > performance. Also the transfer of images in this way is expensive > (regarding time) a screen image is at least copied two times. Then don't use it as a framebuffer -- Framebuffers are *already* a poor fit for modern hardware. Create an image, draw into it, and reuse it. The devdraw model, where textures are uploaded and reused, isn't ideal for modern GPUs, but it's far closer to what is needed, and far easier to accelerate, than software rendering. > So by defining a lower level we could improve the > performance of rendering by a factor of two. While tying tying the code to an unaccelerated model that is not usable over the network. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M2d6d6b65ad50c111a018633b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-01-28 15:49 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-28 2:03 [9fans] suggestion : new service targets for plan9 ibrahim via 9fans 2022-01-28 5:22 ` ori 2022-01-28 11:38 ` ibrahim via 9fans 2022-01-28 7:50 ` vic.thacker 2022-01-28 11:49 ` ibrahim via 9fans 2022-01-28 9:55 ` Frank D. Engel, Jr. 2022-01-28 12:13 ` sirjofri 2022-01-28 12:21 ` ibrahim via 9fans 2022-01-28 14:11 ` Philip Silva via 9fans 2022-01-28 15:27 ` ibrahim via 9fans 2022-01-28 15:44 ` ibrahim via 9fans 2022-01-28 15:49 ` ori
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).