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: Wed Jul 30 14:53:02 2003

On 29 Jul 2003 at 21:40, Rene Wagner wrote:

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

Because you want the API to form an abstraction. Currently the
abstraction is at the 'objects' the same size as the widgets. (I
considering a widget a client-land thing, not driver land)

We have at some point in time decided that the core should not be
concerned with pixels, and I think that's good. We decided the core only
knew nothing smaller than characters. That leaves open what to do with
items bigger than one char. So we'll probably need to decide what to do
with those too.

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

I don't understand what you mean here. There is no information lost
anywhere. The rendering result is derived, and every derived data set
contains less information than the original set (the widget data).

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

I don't see how the rendering code should tell a client that it has some
"wrong instructions".

It has always been the idea that a driver should _try_ to implement a
certain action as good as possible. If it cannot draw blocks, it draws an
other char instead. If it cannot draw partial blocks, it draws bars with
other chars like = or |. A driver can also choose itself how to implement
a heartbeat. If it cannot perform the requested task, you're just
unlucky! It means that the output will not be as nice as you would like.
I don't think we should leave this principle by introducing some kind of
feedback from the rendering process to the client.

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

That's not what I said. The rendering code does not do frames correctly.
For the biggest part the driver code "knows what it is doing", to use
your words.

Yes, it is a design issue. Appearently noone had thought about this.

> a) You know the size of bargraphs because you request bargraphs
> of a given size.

Not exactly. You know the occupied length in chars and the current amount
of promilles it should be filled. It requires a calculation to cut a bar
when it does not fit in a frame. With that calculation you can "fake" the
new size of the bar, but that's not a clean solution.

If we want to solve this we should leave the new way of working with
bargraphs. Maybe we should.

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

OK you propose only to have one char icons.

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

No the driver should decide that. The core does not know what charset a
driver supports, so the driver should decide what to do with unsupported
icons and chars (for example the backslash on many devices).

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

More and more info from the driver... If you have all info of a driver in
the core, you can decide everything in the rendering code. This is an
illusion (as has been discussed before). That is the reason abstraction
is required.

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

What makes you think a bounding box to draw frames is a hack ? It's a
perfect abstraction of a "window" or a "square hole" that looks down onto
a deeper screen with other widgets. OK it's different from the old way of
working where the renderer did the cutting for frames. But it has never
worked for bignums, and I don't know if it has ever worked for bars.

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

Well you decide yourself. To quote myself:

> > 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 :)

Didn't I say that in the first place ?
And am I not using Adobe Photoshop as an example only ?

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

What do you think exactly is the real problem ? Do you mean the fact that
widgets bigger than one char exist ?

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

We _can_ do it in the rendering code, like currently. But I think _IF_
the bounding box function is introduced into the driver, it should work
for _all_ functions, no exception for string. Putting it in _char works
for most functions and most drivers, because they all call _char to
eventually place the chars. _string is the only function that does not
call _char (for most/all drivers).

OK, so is this what you propose:
1. change icon to have only single char icons
2. change bignum in some way. How ?
3. change the vbar and hbar API definition to be able to cut bars at core
level.

Is that right ?

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