9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [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  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  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  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  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  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).