LCDproc development and user support list

Text archives Help

[Lcdproc] bounding box

Chronological Thread 
  • From: reenoo AT (Rene Wagner)
  • Subject: [Lcdproc] bounding box
  • Date: Fri Aug 1 22:30:02 2003

On Fri, 2003-08-01 at 23:50, David GLAUDE wrote:
> Michael Frase wrote:
> >>4. bounding box
> >>- I still think it's not neccessary.
> >>- Please, present the reasons that make it neccessary.
> > If you want frame support you will use a kind of a bounding box !
> > If a widget moves out of a frame has to be cutted of.
> > the "cut-positions" are a bounding box. (if you looked at my new render.c
> > you can find the places where widgets are cutted off !)
> I think we all aggree on that. ;-)

Certainly :)

> > The question is: Should the bounding box be realized in drivers or in
> > rendering code ?
> > Whats the difference ?
> > 1. bounding box in render.c:
> > * render code checks widget position and length
> > * now it compares that info with position, width, height (etc) of frame
> > * if it is needed the widgets lenght will be cutted
> > * therefore only the part in the bounding box ( = visible part of the
> > frame
> > !)
> > is sended to the driver !
> This is the one I like.

Me too-

> I think it is the one you coded.
> It keep the API untouched.
> This minimise the number of API call.
> If it work, then it is great.

We would finally have a clean implementation of frame
rendering, which is a GOOD THING (TM) =)

> > 2. bounding box in driver code:
> > * renderer sends all data (without checking widget position etc)
> > * driver checks every char whether it is in a defined area (bounding box)
> > * if this is true ... the char is drawn !
> I was positive about that one too... It make the rendering easy and
> because a good driver should already have a bounding box that avoid
> writing outside of the physical screen.

I don't think any driver can write outside a physical screen ;)
And I don't really see the point here. The driver deals with single
characters, strings, or icons. It doesn't know enough about the whole
display content at a given moment in time to do anything useful as
far as cutting e.g. strings is concerned.
Most drivers have a framebuffer, some have a backing store. None
of them stores information on which character belongs to what widget

There should not be a situation when the server wants the driver to
display nonsense. That is what the rendering code has to take care of.

> That limit is static, but if it
> exist in the code, making that limit dynamic and having an API call to
> change it would be a good solution.

It doesn't solve anything. What can you do with such a limit? You can
make it a hard limit, sure. But what for?

On the rendering level you have only one place, no duplicate code, and
even more information to not only implement a limit, but also to
implement it in an intelligent way. Intelligent as in you can consider
what type of widget you deal with.

Handling a scroller that is too wide has to be done in a different way
than handling a string. In the rendering code you have the chance to do
so. You simply can't do that in the driver.

> The problem we have is all those driver wich are not good and don't
> verify the input they receave,

A driver can't really verify what it gets for the reasons I've described

> coding in the dark, making the driver
> more complex, make call to the driver where there is nothing to print,
> ...
> There is of course a alternative.
> If you want a simple redering code and not touch the API.
> Then the redering code can call a intermediate layer that apply bounding
> box rules and translate in the necessary call to the driver.

You would lose information that is neccessary to do the error handling
in an intelligent way as described above.

> In your code, all the test, computation are done in that same
> render_frame. This mean we have solution 1. It is however a complex
> function with potential for bug.

But it's one function. A single piece of code, not code that has been
copied and modified in 15+ drivers.

> If you really want uggly code, then we can have two kind of driver,
> those that do present the boundary box API and those that don't.

You don't really want that, do you?

> For
> those that don't we have to do it ourself, and for the good driver we
> can make the right call. We had that kind of fall-back mecanisme for
> driver with missing feature. However, maintaining all those trick and
> accumulating them does not make the code nicer. So avoiding that might
> be good.

It's certainly is a good idea to avoid that.

> There is another good reason for having the bounding box into the
> driver... If driver are to be reused by other project, then each project
> would have to reimplement the bounding box mechanisme (at least those
> that want frame and alike).

First of all it is very unlikely that a different project would want
an API that is not restricted to essential functionality and as small
as possible as far as the number of API calls is concerned.

And actually I don't get it why we should mess with the design
of LCDd for the sake of other projects.



Archive powered by MHonArc 2.6.18.

Top of page