LCDproc development and user support list

Text archives Help


[Lcdproc] bounding box


Chronological Thread 
  • From: reenoo AT gmx.de (Rene Wagner)
  • Subject: [Lcdproc] bounding box
  • Date: Fri Aug 1 21:38:01 2003

Hi all,

On Fri, 2003-08-01 at 22:41, 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 !

"bounding box" as in implementation of a bounding box on the driver
level.

> If a widget moves out of a frame ...it has to be cutted of.

Well... the general question is "What does the server do if it gets
nonsense instructions from the client?"
It is however true that you have to cut widgets that are too wide/high
have to be cut to enforce the frame borders.

> the "cut-positions" are a bounding box.

OK. I would call that the frame though.

> (if you looked at my new render.c
> you can find the places where widgets are cutted off !)
>
> The question is: Should the bounding box be realized in drivers or in
> rendering code ?

In the rendering code.

> Whats the difference ?

There's a huge difference...
Huge, because implementing this on the driver level will leave us with
a huge amount of duplicate code.

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

That's the correct way the rendering of frames should be implemented.

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

As you've described it above it's absolutely possible to implement it
on the rendering level.
And if we can avoid adding new functions to the driver API and if we can
avoid producing duplicate code, why would you not want to do it?

>
> Hope that helps ... Michael

My arguments are still the same, so is my postion.

Regards,

Rene





Archive powered by MHonArc 2.6.18.

Top of page