Re: OpenGL-based framebuffer concepts

["Antonino A. Daplas" <adaplas@gmail.com>]

Pavel Machek wrote:
> On So 03-06-06 07:25:13, Antonino A. Daplas wrote:
>> David Lang wrote:
>>> On Sat, 3 Jun 2006, Pavel Machek wrote:
>>>> I'm not talking about reading speed, I'm talking about displaying
>>>> speed. Once you display more than refresh rate times screen
>>>> size... you may as well cheat -- xterm-like. If xterm detects too much
>>>> stuff is being displayed, it simply stops displaying it, only
>>>> refreshing screen few times a second...
>>> That would work, however AFAIK it's not implemented in any existing
>>> framebuffer.
>> Besides implementaton, the main concern with this is that you might miss
>> a very important kernel message.  Though one can always use the scrollback
>> buffer.
> 
> Well, you can only miss a message *you would not see anyway*.

There are some things that one can see but not read, and still be
recognizable even if your console is scrolling by.

An oops tracing, for one, is very unique and it's easy to pick them off
from regular text, especially on a relatively slow console such as vesafb.
We may even choose to colorize the output so they can stand out further.
  
> I guess
> the main concern is that it tends to look ugly on the screen (and it
> will not be quite easy code).
> 
> Anyway, no, I do not think it is needed. framebuffers are fast enough

I agree, I don't think it's needed.

Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/