Re: Individual file access
Hi Ben, On 16.03.2018 09:38, Nobody III wrote: > ... now seems like a good time to add root > directory passing to the VFS. I may be a bit impatient here, but I'm > hesitant to be the one to make any API changes. That being said, I could > go ahead and make the change if you won't get around to it soon. If that > is the case, how important is backward compatibility here? please have a look at the corresponding issue and the cited commit (on my topic branch): https://github.com/genodelabs/genode/issues/2701 Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Individual file access
Given that we have recently finished a release, and have a few months before the next release, now seems like a good time to add root directory passing to the VFS. I may be a bit impatient here, but I'm hesitant to be the one to make any API changes. That being said, I could go ahead and make the change if you won't get around to it soon. If that is the case, how important is backward compatibility here? On Mon, Feb 12, 2018 at 12:13 PM, Norman Feskewrote: > Hi Ben, > > On 11.02.2018 02:12, Nobody III wrote: > > In order to make the VFS sufficiently dynamic, it seems that the > > Dir_file_system code just needs more sophisticated code to handle config > > updates. Am I correct? > > Yes. > > > As for my VFS plugin, I need a way for it to access the rest of the VFS, > > particularly the root directory. As far as I can tell, this isn't > > possible with the current VFS code. How should we change this? It would > > allow my planned transparent link VFS plugin to work, as well as others > > such as copy-on-write union directories. > > You are spot-on! We definitely need to pass the root directory to VFS > plugins. Actually, I also desperately need this feature. :-) > > However, right now, we deliberately postpone the addition of new VFS > features as we first need to fully nurture the code that we already > have. A look at the issue tracker [1] reveals the construction sites > that should be wrapped up first. > > [1] > https://github.com/genodelabs/genode/search?q=vfs= > open=Issues=%E2%9C%93 > > Cheers > Norman > > -- > Dr.-Ing. Norman Feske > Genode Labs > > https://www.genode-labs.com · https://genode.org > > Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden > Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > genode-main mailing list > genode-main@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Library Isolation
You're probably right. I probably overestimated the overhead of the RGBA -> RGB+A -> RGBA/ARGB conversion. And yes, I invented the RGB+A notation. On Fri, Mar 16, 2018 at 2:25 AM, Norman Feskewrote: > Hi Ben, > > I am afraid that we are getting off-topic but I nevertheless don't want > to leave your question unanswered. > > On 14.03.2018 19:40, Nobody III wrote: > > Are you sure about retaining the separation? For 24-bit color, you can > > either use 32 bits per pixel, or you can force the compiler to use 24 > > bit per pixel, and likely run into alignment issues. If you are already > > using 32 bits per pixel, no extra memory is needed for embedding an > > alpha channel. As far as I can tell, you have already opted for 32bpp in > > Pixel_rgb888. If you use ARGB ordering, no conversion will be needed for > > ARGB -> RGB. > > with using 24 bits per pixel being no option, the obvious downside of > using 32-bit color values combined with a separate alpha buffer is the > waste of the forth byte of each 32-bit pixel value. > > For this reason, I shared your intuition before I practically explored > both alternatives. In particular with my work on the menu view - which > uses 32-bit color depth internally - I first went for the RGBA > representation where the alpha values are interleaved with the color > values. However, the complexity of the result made me uncomfortable, > which prompted me to split the alpha channel from the color values. This > change had the desired effect of vastly simplifying the > software-rendering code while making it more flexible. > > In hindsight, it is obvious why: Alpha values and color values are > different things. Pretending that an alpha value is a forth color > channel is a leaky abstraction at best. It turns two simple but > different (!) objects (color and alpha) into a more complicated object. > All operations on those objects are then bothered with the semantics of > both parts. E.g., in practice, one wants to have the freedom to apply an > operation only on the alpha channel. With RGBA, one needs to craft a > special operation for that. Worse, since this policy is part of the > inner loop of drawing operations (similar to a pixel shader), the logic > around it needs to consider both color and alpha - even if only one part > is used by the operation. In short, by keeping things separate, software > rendering becomes much more simple. > > Another indicator that supports my confidence is the need to supplement > input-mask information per pixel. With 32-bit RGBA, there is no space > for this information. So we need to append a dedicated input-mask buffer > to the pixel buffer anyway. By keeping the alpha values in a dedicated > buffer, we are consistent with the handling of the input-mask values. > > > For my use case, I'd be much better off just using either RGBA or ARGB. > > RGB+A 5:6:5:(separate image for alpha channel) isn't well-supported by > > most libraries. Even Qt doesn't support it. > BTW, I like the notation RGB+A. Is this your invention? > > The framebuffer's representation does not need to be supported by the Qt > API and remains invisible to Qt applications. It is only relevant to the > QPA (platform abstraction). > > > Using your suggestion would > > be lossy, and would require two awkward, slow color format conversions, > > as opposed to (at worst) a single fast, in-place RGBA/ARGB conversion > > for a 32-bit color image. > > I don't share this concern. Genode's graphics performance is already > quite acceptable despite the use of software rendering. Today, > components like VirtualBox or menu view employ in-band color-space > conversion and dithering. Compared to that, the conversion from RGBA to > RGB+A is trivial and certainly faster. > > Second, the output of any non-trivial application is buffered anyway - > simply to avoid artifacts from blitting intermediate drawing states to > the screen. > > As the bottom line, I consider the framebuffer organization as a > technicality and doubt that it is worth arguing about it. Should we find > the RGB+A approach limiting sometime down the road, we can learn from > our mistakes and change it. > > Cheers > Norman > > -- > Dr.-Ing. Norman Feske > Genode Labs > > https://www.genode-labs.com · https://genode.org > > Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden > Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > genode-main mailing list > genode-main@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > -- Check out the vibrant tech community on one of the world's most engaging tech sites,
Re: Library Isolation
Hi Ben, I am afraid that we are getting off-topic but I nevertheless don't want to leave your question unanswered. On 14.03.2018 19:40, Nobody III wrote: > Are you sure about retaining the separation? For 24-bit color, you can > either use 32 bits per pixel, or you can force the compiler to use 24 > bit per pixel, and likely run into alignment issues. If you are already > using 32 bits per pixel, no extra memory is needed for embedding an > alpha channel. As far as I can tell, you have already opted for 32bpp in > Pixel_rgb888. If you use ARGB ordering, no conversion will be needed for > ARGB -> RGB. with using 24 bits per pixel being no option, the obvious downside of using 32-bit color values combined with a separate alpha buffer is the waste of the forth byte of each 32-bit pixel value. For this reason, I shared your intuition before I practically explored both alternatives. In particular with my work on the menu view - which uses 32-bit color depth internally - I first went for the RGBA representation where the alpha values are interleaved with the color values. However, the complexity of the result made me uncomfortable, which prompted me to split the alpha channel from the color values. This change had the desired effect of vastly simplifying the software-rendering code while making it more flexible. In hindsight, it is obvious why: Alpha values and color values are different things. Pretending that an alpha value is a forth color channel is a leaky abstraction at best. It turns two simple but different (!) objects (color and alpha) into a more complicated object. All operations on those objects are then bothered with the semantics of both parts. E.g., in practice, one wants to have the freedom to apply an operation only on the alpha channel. With RGBA, one needs to craft a special operation for that. Worse, since this policy is part of the inner loop of drawing operations (similar to a pixel shader), the logic around it needs to consider both color and alpha - even if only one part is used by the operation. In short, by keeping things separate, software rendering becomes much more simple. Another indicator that supports my confidence is the need to supplement input-mask information per pixel. With 32-bit RGBA, there is no space for this information. So we need to append a dedicated input-mask buffer to the pixel buffer anyway. By keeping the alpha values in a dedicated buffer, we are consistent with the handling of the input-mask values. > For my use case, I'd be much better off just using either RGBA or ARGB. > RGB+A 5:6:5:(separate image for alpha channel) isn't well-supported by > most libraries. Even Qt doesn't support it. BTW, I like the notation RGB+A. Is this your invention? The framebuffer's representation does not need to be supported by the Qt API and remains invisible to Qt applications. It is only relevant to the QPA (platform abstraction). > Using your suggestion would > be lossy, and would require two awkward, slow color format conversions, > as opposed to (at worst) a single fast, in-place RGBA/ARGB conversion > for a 32-bit color image. I don't share this concern. Genode's graphics performance is already quite acceptable despite the use of software rendering. Today, components like VirtualBox or menu view employ in-band color-space conversion and dithering. Compared to that, the conversion from RGBA to RGB+A is trivial and certainly faster. Second, the output of any non-trivial application is buffered anyway - simply to avoid artifacts from blitting intermediate drawing states to the screen. As the bottom line, I consider the framebuffer organization as a technicality and doubt that it is worth arguing about it. Should we find the RGB+A approach limiting sometime down the road, we can learn from our mistakes and change it. Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main