LCDproc development and user support list

Text archives Help


[Lcdproc] bounding box


Chronological Thread 
  • From: joris AT robijn.net (Joris Robijn)
  • Subject: [Lcdproc] bounding box
  • Date: Tue Jul 29 19:15:01 2003

On 29 Jul 2003 at 20:41, Rene Wagner wrote:

> On Tue, 2003-07-29 at 15:04, Joris Robijn wrote:
> > I've had some discussions with Michael Frase about the bounding box and
> > the rendering process.
>
> "*the* bounding box"?
> That term is kind of unkown to me. I assume you want to introduce
> something entirely new...

Well it has been introduced before, but I should have explained some more
about what exactly the idea is. Also see the other mail.

> > Michael said he wanted to work on the rendering
> > process, and to enable him to do that I need to get the bounding box
> > function into the API. It would become:
> >
> > int _set_box (int left, top, right, bottom);
>
> OK... If I understand you correctly you mean introducing this into
> the driver API?

Yes.

> That's totally wrong if you ask me.
> A driver shouldn't have to care about whatever nifty stuff you want
> to do on the rendering level of LCDd.
> Also, I don't see the point in "locking" or "exclusively enabling"
> certain parts of a display.

This is explained in the other mail I just sent.

> The rendering code should know what it's doing and not need any
> "hard limits" in the driver code.

It cannot do it all.

> > This area would from that moment on be the 'enabled area'. Only in that
> > area placements of characters and icons would actually occur. Just like
> > Adobe Photoshop does that :)
>
> Sorry, but I don't think it's a good idea to refer to programs
> that you may be familiar with but others may be not when it's
> about explaining an IMHO drastic API change.

Why do you think it's a drastic change ? It does not change the way any
usual widget it drawn in any way. It would only allow frames to be
rendered correctly.

> > I will also need to adapt drivers for this :( A side effect is that the
> > drivers will then all check for wrong coordinates, preventing writes at
> > wrong memory locations :)
>
> That's a completely different topic.

Yes, that's why I called it a side effect :)

> Every single operation that writes to a certain address in memory
> should _ALWAYS_ double check what it's doing before it actually
> does anything at all.

Agreed, but that does not change the fact that they hardly ever do. Check
the string and char functions in the drivers.

> > If noone object I'll put it in tomorrow (yes I want to rush this a bit :)
>
> A clear NO! from my side unless you explain what exactly you
> want to do including details on why it is neccessary.
>
> Also, I don't think a time frame of a _single day_ is appropriate
> for anything important concerning changes to the server
> core, the driver API, or the client protocol.

OK point taken.

> I really appreciate every single improvement to the rendering code,
> but we should stick to normal development rules.

OK I should have given more info and taken more time. But come on, we
should move on ! 0.5 development should continue actively and 0.4 should
have a new release. Let's keep this locomotive running.

Joris
--
Joris Robijn
<joris AT robijn.net>
Mobile: 06 288 41 964

// To understand recursion, we must first understand
recursion





Archive powered by MHonArc 2.6.18.

Top of page