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: Tue Jul 29 19:38:02 2003

On Tue, 2003-07-29 at 20:11, Joris Robijn wrote:
> > In order to avoid a big period of time where 0.5 will be broken for most
> > driver, it would be nice to freeze and make downloadable a nightly build
> > so that if CVS or new nighlty build are broken, it is still possible to
> > have one of the latest working 0.5 (without that nice feature).
>
> It should be committed as one thing. Then there is no problem (if it's
> done properly of course)

The problematic thing about driver or driver API changes is that
you simply don't have all the hardware that would allow you to
test what you've done...
So, at the end of the day, you will always need those who have
the hardware to at least confirm that your changes are correct
and don't break anything.
Of course you can do some "coding in the dark" (TM), but that is
nothing you could seriously describe as a wanted.

>
> > > int _set_box (int left, top, right, bottom);
> >
> > Is this a "protection" box that garanted I can not write outside of
> > boundary box (nor above, nor below) but does not change the fact that
> > coordonate (2,4) is still the physical (2,4)?
>
> Correct. No offset is introduced in the driver, to keep things simple.
>
> > Now how do we reset the _set_box to the default value?
>
> By doing set_box(1, 1, width, height). The rendering process should do
> this when it renders the current screen, and call it with other values
> when it renders a frame.
>
> > Are the left/top/right/bottom included or excluded (is it [left,right]
> > or ]left,right[ or [left,right[ ...
>
> Yes. a || b || c || d ;)
> But seriously: all included. The values are the minimally/maximally
> allowed values. 1-based, like all coordinates.
>
> > Is it not a good time to choose between (0,0) or (1,1) to be the top
> > because it seems most driver do -1 or +1 when they receave parameter?
>
> You think we should change that ? I've just got used to 1-based
> coordinates everywhere.

1 based or 0 based is a question of getting used to the one or the
other system. That is certainly not among the things that would
have any positive effect as far as functionality is concerned.
And I suppose we would have to change the client protocol which
is a DON'T if you ask me.

>
> > Is there any reason why this thing can not be done in central server
> > code? If it is only a filtering, then what is the problem.
>
> No that's what we have dicussed about the frames. It's about widgets
> bigger than one char (bars, icons, bignums). They _should_ be cut by the
> driver, because the rendering code simply _cannot_ do this.

Well, *why* not?
You can push the problem to whatever place you want, it will remain
a non issue because it doesn't solve the real problem.

You will end up with garbage on the dipslay whenever there is an
error in the long "chain" of various layers that are involved in
getting information from a client to the display.

Wherever you insert a cut you will always corrupt the information.

So, the question is where do you know most about what you are
supposed to do as the server dealing with unclear of wrong instructions.

That particular "place" seems to be the rendering code.
Simply because you have both, information on the instructions you've
received from a client AND information on the display which you
can retrieve from the driver.

Now, if you say the rendering code doesn't know what it's doing
then that must be because there is something wrong about the design.

a) You know the size of bargraphs because you request bargraphs
of a given size.
b) Icons should always consume the space of a single character.
I do know that this is not the case ATM, but trying to "fix"
that design error by introducing more and pretty complex stuff
into the drivers and thus enormously increasing the amount of
redundant code can't be justified as a solution.
You can request a special icons from the driver. If it doesn't
provide that icon it must return some sort of error code that
allows the rendering code to fall back - first to more standard
icons and if those don't exist to general characters provided
by all drivers.
The rendering code will then be able to decide what to do if an
icon doesn't fit on screen or on a frame/window/whatever.
The driver simply can't do that because it knows about a single
character/icon only and doesn't have the complete instructions
set/the whole "image".
c) Handling big numbers should be implemented in a different way,
too. The driver knows their size, the rendering code doesn't,
which is wrong.
If you want to change the driver API, feel free to introduce
some getFoo() functions that retrieve information from the driver.
You can then always have default implementations that use the
"standard" definitions that are used ATM (3x4 for big numbers)

>
> > Other option, if that filtering is possible to do without knowledge of
> > the driver internal, then a generic solution can be found for all driver.
>
> If you know a way to do that :)

Sorry, but that approach doesn't help here.
It helps if you need a quick hack AKA workaround, but not if you want
a clean solution. And there is no room for hacks if an API is
concerned.

>
>
> > > 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 :)
> >
> > I don't know about Photoshop, maybe you are talking about a Gimp clone?
> > Is there a patent on that feature?
>
> Adobe Photoshop = the standard in DeskTop Publishing.

Sorry, but, to quote Maddog Hall, you seem to be one of those who
"still do not understand"...
(http://www.linuxtag.org/2003/de/conferences/talk.xsp?id=58)
Photoshop is a product not a standard.

> If anyone has
> patented the idea of a rectangular selection, I'm going mad.
>
> In Adobe Photoshop, when you have selected an area of you image, you can
> only draw/delete/modify in that area.

So, why not just say that in the first place?

>
> > Ok for the rush...
> >
> > But a description of how it will work and how it worked before would
> > help the debate:
>
> Ok, sorry, I presumed it known because we had already discussed it a lot
> in the past. I guess I should have freshed it up first. And from what you
> have commented so far it's already clear that there are many ways you can
> implement it.

Correct. So give us time to discuss and find the approach that is
clean and doesn't introduce new problems or doesn't fix the real
problem which I think is the case here.

>
> > set_box (2, 2, 10, 3);
> > set_icone(15,4,HEARTBEAT);
>
> Nothing on LCD because all the characters of the icon are outside of the
> indicated area. Although set_box should only need to be called once when
> a screen or frame is starting to be rendered, not before every widget.
>
> > Actually I take 2 weeks of vacation starting from friday, so it might be
> > short to adapt any driver I usualy care for. ;-)
> > Except if it is really rushed and exchange with my family 2 week without
> > laptop/internet against a night of LCDproc coding...
>
> Ah you have something to trade with :)
>
> I guess it's easier if I do that.

The fact that you think you could do it without knowing all the details
on all drivers clearly proves that you can do it on the rendering level.

You do have the information you need there and only there. If that
is not the case something else must be wrong (see above).

> But if you want to do that, it's easy.
> I can send you a modified lcd.h... Then this needs to be done: add
> _set_box to the driver, add box variables to driver, add code to check
> the box in _char and _string. _string is not as the easy as char because
> it requires string cutting when a part of the string is outside the box.

That's too much for the driver code.

> Let me wish you a good vacation already.

Yeah, have some nice days, David. Free from computers/laptops
I hope ;) [unless you really want to of course].

Regards,

Rene





Archive powered by MHonArc 2.6.18.

Top of page