Thiede,

Do you find Widgets useful?

On Wed, Oct 23, 2019 at 12:24 AM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> Hi Dave,
>
>
> many thanks for the pointer! The #extent: implementation in my
> image actually does not call #rounded - this is because I have installed
> Widgets <https://github.com/hpi-swa/widgets> which contains an extension
> method based on an older implementation of #extent: ... Will report or fix
> the bug there. Thanks.
>
>
> Best,
>
> Christoph
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von David T. Lewis <lewis at mail.msen.com>
> *Gesendet:* Mittwoch, 23. Oktober 2019 03:20:43
> *An:* The general-purpose Squeak developers list
> *Betreff:* Re: [squeak-dev] Fractional bounds and flickering (contains
> images that may be disturbing to some readers)
>
> I cannot reproduce in my image either. The fractional bounds are
> rounded to integer values in Rectangle>>rounded, which is called
> from Morph>>extent.
>
> Dave
>
> On Tue, Oct 22, 2019 at 01:09:23PM +0000, Thiede, Christoph wrote:
> > Hi Nicolas,
> >
> >
> > thanks for the insight. On my system, it is not rounded ... I have the
> latest trunk updates installed.
> >
> > ________________________________
> > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
> > Gesendet: Dienstag, 22. Oktober 2019 15:00:27
> > An: The general-purpose Squeak developers list
> > Betreff: Re: [squeak-dev] Fractional bounds and flickering (contains
> images that may be disturbing to some readers)
> >
> > Hi Christoph,
> > I cannot reproduce. It seems like bounds soon get rounded in my image:
> >
> >     (SystemWindow new openInWorld extent: (24214/31)@(11565/31)) bounds
> extent.
> >         781 at 373
> >
> > Le mar. 22 oct. 2019 ? 13:40, Thiede, Christoph <
> Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:
> Christoph.Thiede at student.hpi.uni-potsdam.de>> a ?crit :
> >
> > Hi all,
> >
> >
> > In the latest days, I encountered flickering problems caused by
> non-integer bounds of system windows again. For me, the following fails
> reproducibly in different images:
> >
> >
> > SystemWindow new openInWorld extent: (24214/31)@(11565/31).
> >
> >
> > If I hover and unhover the window a few times, its contents are drawn
> badly and incompletely like this:
> >
> >
> > [cid:16df38cc226f456b1e51]
> >
> >
> >   *   As you can see, the issue also affects other morphs in the same
> region (in the screenshot I am hovering the implementors button of the
> background browser).
> >   *   The issue only occurs with very complex fractions, so the extent
> 500 @ 300 / 2 would not be a problem (at least in my image). I could not
> reproduce it using floats.
> >   *   The situation can be also reproduced by composing a few morphs
> manually, but the more submorphs there, the higher the flickering rate
> appears to be.
> >   *   [World imageForm] does not contain any abnormalities, maybe the
> problem is related to the damage recording?
> >
> > I would like to solve this bug, but I'm not sure where the problem
> actually arises. In general, should morphs be allowed to have non-integer
> bounds? This could be useful e. g. for exact animations, but we already
> have some rounding that (unfortunately) rule out this use case:
> >
> >   *   #position: appears to round the delta value for movement
> >   *   #extent: and #bounds: do no rounding at all.
> >
> > Should we maybe apply some rounding or at least truncating there? Or
> just convert the arguments using #asFloat before?
> > Or do you have any idea how one could debug the problem?
> >
> > (For relevancy: I often call Preferences >> #changeFontSize:, and each
> time all windows are drawn badly until I round their bounds. This can
> indeed be quite annoying:
> > [cid:16df38cc227f456b1e52])
> >
> > Looking forward to your help!
> > Best,
> > Christoph
> >
>
>
>
>
> >
>
>
>
>

-- 
John-Reed Maffeo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191023/15848664/attachment.html>