[Cuis-dev] Slow keyboard input

[Luciano Notarfrancesco]

Cool, thanks for the explanations. At some point the canvas was responsible
for drawing the coordinate system on the halos, right? Maybe that thing
with the halo cames from that? Or maybe some other experiment, I seem to
remember that at some point you highlighted the target of the halo, and it
required redrawing, it could be related to that? I’ll remove that code in
my image and see if I run into any problem. Thanks!

On Sun, 30 Jan 2022 at 3:50 AM Juan Vuletich <JuanVuletich at zoho.com> wrote:

> Hi Luciano,
>
> I don't have a real solution for these issues now, but some comments
> that may be useful.
> (inline)
>
> On 1/29/2022 5:06 AM, Luciano Notarfrancesco via Cuis-dev wrote:
> > Hi Juan,
> > I start from the newest image from the repo, install new updates, and
> > then load all TrueType fonts.
> > It’s not a very big deal, it’s usable now that I fixed my own code to
> > avoid forcing everything to redraw every second, and feels even
> > smoother with HybridCanvas. Anyway I looked at it a little with
> > AndrasSystemProfiler and it seems that every keystroke on a workspace
> > triggers redrawing the full workspace, spending time mostly filling
> > the background twice (first for WorkspaceWindow and then
> > TextModelMorph). But I don’t understand all the details of how the
> > world is drawn, maybe this is perfectly normal. And I guess it is
> > nontrivial to compute a smaller area to redraw when a character is added.
>
> Disabling syntax highlight removes one of the background fills. I
> believe this is because with syntax highlight, some fonts may have
> different glyph metrics for different styles, so all text could reflow.
>
> In any case, #fit clearly needs some attention to optimization to avoid
> unneded redraws. Right now, it only tries to be sure to update if needed
> (or even if not!).
>
> > Also, if I open a browser, then open the halos in the browser and move
> > the mouse pointer over the system categories list, every time a list
> > item is highlited the whole browser is redrawn. This doesn’t happen
> > without the halo, in that case only the unhighlighted and highlighted
> > items are redrawn. To see the redrawing I changed BoxedMorph>>drawOn:
> > to use ‘Color random’ instead of ‘color’.
> >
>
> In #updateBoundsIn:addDamageTo: (be sure to tweak it in the active
> canvas class to see effects) the haloMorphsDo: iteration effectively
> means that if a morph has a halo, and some inner submorph
> #isRedrawNeeded, the it marks the halo as #redrawNeeded. But later, when
> dirty rectangles are merged to reduce the number of draw operations, it
> ends redrawing everything in that rectangle.
>
> Truth is that I don't know why the halo is marked like that. I don't
> remember why was that needed, and I don't see ill effects if I
> completely remove that iteration. And the bogus drawing you see goes
> away. Maybe this is the solution for this one.
>
> Thanks,
>
> --
> Juan Vuletich
> www.cuis-smalltalk.org
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> https://github.com/jvuletich
> https://www.linkedin.com/in/juan-vuletich-75611b3
> https://independent.academia.edu/JuanVuletich
> https://www.researchgate.net/profile/Juan-Vuletich
> https://patents.justia.com/inventor/juan-manuel-vuletich
> @JuanVuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220130/0d270254/attachment.htm>