Revisit [REVIEW 3-5] some shape position skew

[Noel Power]

On 08/06/12 11:56, Noel Power wrote:
> although 31012ab9d7035f942486c87ecc1a79b4d6579975 ( and associated fix 
> 8a838b9fbf46ece9680824cd3a044ab7338bf306 ) make the document mentioned 
> in https://issues.apache.org/ooo/show_bug.cgi?id=116848 behave better 
> with zoom, it makes other documents much worse ( even at 100% zoom ) 
> e.g. the document attached to  fdo#49430. When you modify the zoom 
> then the situation gets much much worse. So what I see is
>
> a) with commits 31012ab9d7035f942486c87ecc1a79b4d6579975 ( and 
> associated fix 8a838b9fbf46ece9680824cd3a044ab7338bf306 ) we have one 
> test document ( associated with the orig bug ) that experiences no 
> skew of the relative position of the shape to the position of the cell 
> the shape is anchored to ( regardless of the zoom ). However we have 
> other documents ( typically where the shapes are located further down 
> the document ) where there is significant skew between the shape 
> position and associated cell it is anchored to. Note: in these cases 
> changing the zoom results in wild relative position changes ( e.g. a 
> number of rows offset )
>
> b) with the commits above reverted the test document associated with 
> i#116848 is indeed not behaving itself at zoom levels other than 100% 
> ( so that bug will still exist ) but... with the other scenario ( with 
> shapes located much further down the document e.g. with the document 
> attached to fdo#49430 ) behave much better, indeed the shapes ( at 
> 100% zoom ) are at the correct position. In both cases changing the 
> zoom seems only to affect the relative position error in a small way ( 
> e.g. less than a row height )
>
> Eike we discussed this previously on IRC and I already reverted these 
> patches on master, I think we should revert these on 3.5 also, to me 
> the behaviour without these commits is better than with them ( but 
> thats just my opinion hence the review request ) It would be great to 
> fix the underlying error, unfortunately I didn't have any luck with 
> that. So... please consider reverting 
> 31012ab9d7035f942486c87ecc1a79b4d6579975 ( and associated fix 
> 8a838b9fbf46ece9680824cd3a044ab7338bf306 )
so. I have returned to this a number of times, I must confess I never 
did seem to figure out how to avoid the rounding effects inherent with 
how the grid is drawn ( row by row ) and how the that compares with the 
fixed position of some shape over different zoom levels. As we know the 
resultant effect is that the position of the shape seems to change 
relative to the grid. So.. I took a different approach and try to 
minimize those ( what seems to be inevitable ) display errors. First I 
find the nearest cell to the shape, then find out where that cell is 
drawn on the screen for the current zoom, and lastly move the shape ( 
before it is drawn ) to compensate for any errors. The idea is simple 
enough but the patch is rather ugly ( especially around the mark view 
stuff, add offset here, remove it there etc. must be a better way I feel 
) . Anyway It does seem to work reasonably well though ( at least all 
the shape things I tried on the draw toolbar and inserted pictures 
charts and ole objects ) *seem* to work. I say *seem* because I have to 
admit that I haven't retested *all* of these objects after every change 
( and there were many individual changes sofar to try and tease out the 
wrinkles ) but I have tested most of them again just before I committed

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c4e649f0cd013e86adbd794859bcc3cb9ee3aa61

note: make check passed

so, please beaware of this change, let me know if you spot any new 
unusual behaviour around this area. One thing I did notice is that after 
creating some shape/object at some non 100% zoom level that sometimes it 
is difficult to get the handles ( after clicking the object ) again for 
the shape after creation. Actually I thought I fixed this earlier but 
perhaps some more recent change I did broke it again :-(
Anyway there are I am sure lots of edge cases around this that I haven't 
yet spotted, please help find them.

A quick demo screencast ( and the test document used in the screencast ) 
is located here http://users.freedesktop.org:8080/~noelp/zoom , best to 
download the video in order to see the subtitles ( not really visible 
when you play from the browser ) and as poor as the subtitles are they 
took me half the day to figure out how to do them

Noel