LCDproc development and user support list

Text archives Help

[Lcdproc] bounding box

Chronological Thread 
  • From: dglaudemailing AT (David GLAUDE)
  • Subject: [Lcdproc] bounding box
  • Date: Fri Aug 1 21:51:01 2003

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. ;-)

> 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.
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.

> 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. 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.

The problem we have is all those driver wich are not good and don't
verify the input they receave, 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.
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.

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. 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.

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). So this is also code replication. But
1) Those are other project, they can fork if they want an other API.
2) We currently have one server and 20 (just guessing) drivers, if we
had 20 project reusing the same single driver... then changing that
driver code maybe would have been acceptable.

Don't let the computer/expert control the election
Information for Belgium in french:

Archive powered by MHonArc 2.6.18.

Top of page