On Tuesday, February 22, 2022 at 11:13:34 AM UTC-5 T. Modes wrote:
>
> For the synchronized scrolling the images need some overlap. If the
> overlap is too small it does not work so good, but for a normal overlap it
> works here.
>
> I tested with about 30% full image overlap on Windows and
johnfi...@gmail.com schrieb am Montag, 21. Februar 2022 um 21:24:47 UTC+1:
> I should have repeated my earlier statement that my committed code should
> only be tested with non-float images. It has a serious performance flaw
> for float images. That should be easy to correct, but I expected
I should have repeated my earlier statement that my committed code should
only be tested with non-float images. It has a serious performance flaw
for float images. That should be easy to correct, but I expected you to
have a strong opinion on where/how that should be corrected, and I thought
On Sunday, February 20, 2022 at 10:55:26 AM UTC-5 T. Modes wrote:
>
> I asked you several times not to mix up several things in one commit. You
> still mixed up several unrelated code changes in one changeset. (Yes, they
> have both the same target. But the code changes are totally unrelated.
johnfi...@gmail.com schrieb am Samstag, 19. Februar 2022 um 18:57:37 UTC+1:
> I pushed the change discussed here to my branch.
>
> Hopefully someone else will try building and testing it.
>
I asked you several times not to mix up several things in one commit. You
still mixed up several
I pushed the change discussed here to my branch.
Hopefully someone else will try building and testing it.
With this change, higher zoom level no longer affects memory use: All
levels other than 100% and "fit" have the same memory use as each other,
and that memory use is lower than any of
Scrolling tends to be a place where wxWidgets might issue a excess number of
redraw steps.
In all other cases if the intervals at which onDraw is called are strange I
would wonder where Hugin triggers that.
The wxWidgets application I maintain (wxMaxima) draws the whole worksheet as a
bitmap
On Thursday, February 17, 2022 at 1:23:54 PM UTC-5 gunter.ko...@gmail.com
wrote:
> I don't know if that is the case here. But if the GUI feels sluggish one
> typical reason is that you try to update the display for every single mouse
> event you get sent (which means that if you draw
The same "speedup" method is used by the real time Linux kernel: The
default kernel acts on every interrupt as fast as possible and by doing
that saves every CPU cycle it can. But on slow computers that feels
sluggish.
The real time kernel patch makes every interrupt set a flag that tells the
I don't know if that is the case here. But if the GUI feels sluggish one
typical reason is that you try to update the display for every single mouse
event you get sent (which means that if you draw slightly slower than your
19200dpi-7ms-latency-mouse sends data you start to fall behind with
I recently rewrote my local change for saving memory in the CP editor, to
make it more suitable for committing on the branch with my other changes.
I ran into a bunch of performance side issues (yes, it saves memory, but
the savings vs. cost in cpu time are a much trickier topic).
I have only
11 matches
Mail list logo
