[Libreoffice-commits] core.git: Changes to 'feature/calctiledrendering4'

Andrzej Hunt andrzej.hunt at collabora.com
Fri Jul 11 07:38:47 PDT 2014


New branch 'feature/calctiledrendering4' available with the following commits:
commit 54070217e629719a3fd94a7f071051056c135873
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Fri Jul 11 16:35:58 2014 +0200

    More pixel->document coordinate scaling.
    
    Change-Id: Iea3877c024d66fa6b80d447c749246148f2dc11d

commit 8772ef136318bb589a0484cc37ec171fe3829b2d
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Fri Jul 11 10:23:15 2014 +0200

    Add png dumping to LOK tiled rendering test.
    
    This allows for easier visual comparisons (i.e. currently the test
    would be failing for some tiles).
    
    Change-Id: I5b174375b57ffe0edd2700fdec411a83669e4a34

commit 293e9332629a5afbb2b08b870af80399b7b98d3a
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Fri Jul 11 09:07:06 2014 +0200

    DON'T MERGE: the viewport doesn't get set otherwise?
    
    When writing the tiled rendering test, asserts were firing because the
    redraw area wasn't set on the page -- however I don't understand
    things well enought yet to know whether or not this is the correct
    solution.. (Especially as this happened only for certain tile configurations.)
    
    Change-Id: I187d639b00d0748e7cc9fd6cc33d555f02f9a081

commit 5087e21970a3f62f4f62348d79ce3b9df85eec1c
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Thu Jul 3 14:47:15 2014 +0200

    Iterate from origin to tile area to ensure correct positioning.
    
    Change-Id: I29e881f9e67b84e208a198d2aad06db382d14698

commit 8265a55aa036d2453521723ca57e9ef27228639b
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Thu Jul 3 14:46:32 2014 +0200

    Use logic units for visible-cells determination.
    
    This eliminates a bunch of LogicToPixel conversions, and also
    means that tiles starting other than the origin are correctly
    processed (as LogicToPixel run on a rectangle will also move that
    rectangle depending on the origin set in the output device).
    
    Change-Id: I42903fe23ad5f6baa1d5276d5dcc7ee038bd27cf

commit b539322e04f1a9ea797725309c0797952935c72c
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Thu Jul 3 14:43:28 2014 +0200

    Scale the origin for the Draw Layer (Calc Tiled Rendering).
    
    Since we're changing units, we also need to scale the origin
    by the correct amount.
    
    Change-Id: Ie0563376e8fa56f20c30da4fe3cc50546f18e84f

commit 2475c5436771b496a37735bac6cb015a90c75fbd
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Wed Jun 25 22:37:54 2014 +0100

    Use OutputDevice scaling for column-/rowbars too.
    
    This means we now match the new gridwindow dimensions. There
    are however some issues around selection/painting now, which
    are presumably related to some parts of the code still assuming
    pixel rather than logical dimensions.
    
    Change-Id: I15c2bc7210f26cededd63bc89dbd782e6e4c03b8

commit fe0373c9b706ce524bf4e53c347ee14f256638b5
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Thu Jun 26 17:06:58 2014 +0100

    Ensure we actually render all cells in the selected area.
    
    Only cells within maVisibleRange are rendered, even if we request
    a larger area (and maVisibleRange is otherwise not updated for tiled
    rendering). Hence we should explicitly set it here.
    
    Change-Id: I399be9df1f266a2b3d32a95483960b21f561c6b3

commit 44d0332017e786413a5eb77d1e101068f66f0623
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Thu Jun 26 14:30:08 2014 +0100

    Take into account drawing layer for data area size.
    
    The drawing layer could potentially have items that are outwith
    the data area, but we probably want to have them included for
    tiled rendering.
    
    Change-Id: I958c4fa29491cdb0fd80392dfcfa033306f2b76c

commit cd065ed0888db078bf8ff5fddb5ba5334e6f596c
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Tue Jun 24 22:06:59 2014 +0100

    Use output device mapping for draw layer too.
    
    Otherwise draw layer items don't get scaled at all for tiled
    rendering.
    
    Change-Id: If65d460a83fb29b8eda692cb7c1f2bd9f7283e62

commit cac4196fdaf200dd08290d65d6e7fb39fd7cbefb
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Fri Jun 20 11:07:33 2014 +0100

    Set correct scaling for normal painting.
    
    As we no longer read the scaling from the viewdata, we should
    instead set it on the output device when doing normal rendering.
    
    However the grid still doesn't exactly match the external axes yet,
    there are probably more rounding errors wherever they are painted.
    
    Change-Id: I25b1bd9b344115578fe892aa94fbf753a3c10c81

commit da64c58871fe3378eb2cee8619f3d96ded4f2d93
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Fri Jun 20 10:35:45 2014 +0100

    Use output device scaling to determine cells in draw-area.
    
    Change-Id: Idf4e6ccb72090a55b6a9234cafae21821e3df0b0

commit f77ef66c9c295a2cf2c50e4f180bfe69ec1d5759
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Fri Jun 20 09:38:50 2014 +0100

    Don't scale grid and cell dimensions multiple times.
    
    Previously we had multiple layers of scaling, with rounding
    errors propagating, leading to up to 5% differences in expected
    and rendered sheet widths -- for tiled rendering dimensions have
    to scale accurately as we may paint the same tile at multiple zoom
    levels, by eliminating multiple scaling and letting the output
    device instead deal with the scaling once we can eliminate these
    errors. (However currently rendering of text/images isn't quite right.)
    
    Change-Id: I0a725fd5c030f3c089c2bbd25947088c321eb2d4

commit 6f079c4733fb1c61c0ecdf9f96afc4b2c1181bbd
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Wed Jun 18 09:33:16 2014 +0100

    Implement data area size retrieval.
    
    Cell dimensions appear to be in TWIPs (but the drawing layer is in 100th mm).

commit a44d6a802df00072d0538fe84e83b2b59ba04b29
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Wed Jun 18 08:28:04 2014 +0100

    Allow overriding of device for Paint, and use that for Tiles.
    
    Paint handles figuring out which cells are within the visible area
    for us etc.
    
    Gridwin being a Window which paints to itself is a bit of a pain,
    since we now need to be able to reroute painting calls to alternative
    output devices, however these changes seem to be sufficient to at least
    get the cells in the desired tile rendered.
    
    Change-Id: I7bd1434c97acc6e9ef6e1e63cbcf039b987c88e4

commit 5c3efd0739fba25530642cc16b0e45d5611f5b74
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Mon Jun 16 16:19:56 2014 +0100

    Calc: Add tiled rendering device to the paint view.
    
    This prevents the previous warnings of
    SdrPageView::DrawLayer: Creating temporary SdrPageWindow (ObjectContact), \
    this should never be needed
    
    Change-Id: I76cb7c9ed4d45bfcbd297f697314309b4e036f80

commit f3ee5edaf550c9683ee4b1bb7736e7bfaefd61c4
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Mon Jun 16 15:00:02 2014 +0100

    Render tiles from calc.
    
    Currently the document size and number of cells to be rendered
    is hardcoded, this will need some more work to select the correct
    cells for a given tile (i.e. cells from location). Also, there
    isn't really a "size" for a calc sheet, so presumably we'd need
    to instead return the area containing cells that aren't empty,
    whilst still being able to render larger tiles? (And in any case
    the client will need to be aware of this and provide an appropriate
    interface, i.e. the current LO UI simply extends the sheet ad-infinitum.)
    
    We also currently get some warnings most likely related to the way
    we push our OutputDevice into the rendering methods:
    SdrPageView::DrawLayer: Creating temporary SdrPageWindow (ObjectContact), \
    this should never be needed
    
    Change-Id: Ia9d64d7de6c22d5b401350f88497a7ec106f1973



More information about the Libreoffice-commits mailing list