Created attachment 170510 [details]
screenshot

Here's a screenshot that hopefully shows why it is problematic.

Something like this perhaps?

 const ScreenPosition = {
@@ -1124,10 +1124,12 @@ ZoomRegion.prototype = {
         let [xRoi, yRoi, widthRoi, heightRoi] = this.getROI();
         let halfScreenWidth = global.screen_width / 2;
         let halfScreenHeight = global.screen_height / 2;
-        let xProportion = (halfScreenWidth - xMouse) / halfScreenWidth;
-        let yProportion = (halfScreenHeight - yMouse) / halfScreenHeight;
-        let xPos = xMouse + xProportion * widthRoi / 2;
-        let yPos = yMouse + yProportion * heightRoi / 2;
+        let xPadding = global.screen_width / 10;
+        let yPadding = global.screen_height / 10;
+        let xProportion = (halfScreenWidth - xMouse) / (halfScreenWidth - xPadding);
+        let yProportion = (halfScreenHeight - yMouse) / (halfScreenHeight - yPadding);
+        let xPos = (xMouse - xProportion * xPadding) + xProportion * widthRoi / 2;
+        let yPos = (yMouse - yProportion * yPadding) + yProportion * heightRoi / 2;
 
         this._scrollToPosition(xPos, yPos);
     },

(In reply to comment #2)
> Something like this perhaps?
> -        let yProportion = (halfScreenHeight - yMouse) / halfScreenHeight;
> -        let xPos = xMouse + xProportion * widthRoi / 2;
> -        let yPos = yMouse + yProportion * heightRoi / 2;
> +        let xPos = (xMouse - xProportion * xPadding) + xProportion * widthRoi
> / 2;
> +        let yPos = (yMouse - yProportion * yPadding) + yProportion * heightRoi
> / 2;

I think it's confusing to "pad" the position (especially with the unnecessary parenthesis). Does it make sense to write this as follows?

let xPos = xMouse + (widthRoi / 2 - xPadding) * xProportion;
let yPos = yMouse + (heightRoi / 2 - yPadding) * yProportion;

Created attachment 170762 [details]
Top right with proportional mouse tracking

(In reply to comment #1)
> Created an attachment (id=170510) [details]
> screenshot
> 
> Here's a screenshot that hopefully shows why it is problematic.

I see what you are saying, and have been experimenting with possible solutions.  One (partial) fix is simply using the full screen size and not halving it at the beginning of the calculation.  "PropRight.jpg" is a screen shot of what happens in that case.  How does it look?

Misgivings:  Using this technique, I don't see similar "padding" on the top-left, and I'm not sure if the magnification factor interacts with this in some way.

I think what you want is for proportional tracking to stop near the edge, and behave similar to the way centred tracking does (near the edge).

I just tried o(In reply to comment #2)
> Something like this perhaps?

I tried your padding solution.  It's much better than the suggestion I made above.

Anyone want to cook up a patch for this?  More important now since this is the default mode.

Created attachment 174464 [details] [review]
Improve the algorithm for proportional mouse tracking

Here's my attempt to turn things into a patch. Changes:

 - Made the padding region dependent to the zoom factor so it wouldn't
   be a larger fraction of the ROI at higher zoom levels.
   (Try, say, gsettings set org.gnome.accessibility.magnifier mag-factor 4
   to see the effect)

 - Switched the sign on xProportion/yProportion, since the existing
   convention was hurting my head, Positive numbers increase towards the
   left!

 - Used the screen height for both X and Y padding, since it seems like
   the factors determining padding size would be the same in the X and Y
   directions.

The patch depends upon my ZoomRegion refactor in bug 633582.

Review of attachment 174464 [details] [review]:

Looks good. Jon, can you confirm that this is the behaviour you want while the required patch is pending review?

Fixed with algorithm changes for computing the padding in the non-full-screen discussed and tested on IRC.

Attachment 174464 [details] pushed as 96fb6d8 - Improve the algorithm for proportional mouse tracking