I attached a xoj file and pdf files, one rendered by old xournal and one by my version. Note that this xoj file has been created by an old xournal, so the line width at the very beginning of the stroke didn't get recorded. If I had drawn the same stroke with my version of xournal, most likely also the first (top left) segment would not have had constant width.
Am 04.09.2016 um 03:50 schrieb Denis Auroux:
On 09/03/2016 09:21 PM, dmg wrote:I think that the n+1 vs n widths can be easily handled by patching xournal to accept a n+1 width (and ignore it). So when it reads a file with more than n, it works, rather than failing as it is currently. I'll write the patch today.Yes, of course -- but it does break backwards compatibility of the file format (in the sense that existing versions without this easy patch won't be able to read the new files anymore, for a reason that feels slightly stupid). In general, if we want to treat trapezoid vs lines as purely a rendering option then we need to agree on how many width parameters need to be stored regardless, and do so in a manner that can still read existing xournal files without getting too confused. Hah. It's a bit of a hack, but here's a proposal that fully preserves file format compatibility: * We add one more width as Immi would like us to (presumably this is the width at the start of the stroke -- I looked at my code and it only measures the pressure/width at the end of each segment -- we only call get_pressure_in continue_stroke(), so the extra width that Immi needs to store presumably comes before the others) -- but we also add one more xy point: we record twice the starting point of the stroke. * Then the existing versions of xournal and the sequence-of-line-segments renderer should be able to treat this just fine if they read this kind of stroke data -- it would just start by drawing a length zero segment. Meanwhile, the trapezoid renderer would either ignore the initial length zero segment if there is one [for data coming from the new xournal], or if the initial segment does not have length zero, draw a line or a triangle [note: the initial nonzero length segment indicates that we're missing one piece of width data because the file came from an older xournal, so one needs to improvise], and then draw trapezoids for the subsequent line segments as required. (Sorry if this is a bit confusing. Old format = we store n+1 distinct points and n widths for the end of each segment i.e. no width data at the starting point; new format = we store the first point twice, ending up with n+2 points in total, and n+1 widths at all the distinct points (= the ends of the segments if you include the duplicated first point in the list). Then there's enough data for the trapezoid renderer if the first point is duplicated [otherwise, in existing xoj files there isn't quite enough width data for the trapezoid renderer and the first line segment needs to be treated creatively], and the duplicated xy-point allows old versions of xournal to think that this is just a sequence of widths for the segments, the first width being for a bogus length 0 segment.) Does this make sense? [as in: do you agree it would work?] Does it make
Yes, I agree that this should work.
sense? [as in: do we think it's worth introducing such a hack to preserve compatibility?]
I definitively think that compatibility is important, and your proposal might indeed be the best solution.
I'll implement it. Concerning: > Optimization: I believe it's a matter of not requesting a new > different line width for each line segment, instead grouping together > consecutive segments that have very similar widths and drawing them > in one go -- but I am not sure if I got it right. > (I am surprised that overall this speeds up rendering, I would have > expected trapezoids + circles to be slower than line segments but I > guess I must be wrong. [or perhaps it depends on the graphics drivers > and available acceleration?]. I don't know how to profile this, but a > naive test might be to make a document with TONS of variable-width > strokes and find out how long it takes to render.]It seems that the main reason it's faster is that it greatly reduces the number of canvas items, since consecutive segments of similar widths are drawn as one item.
The occasional trapezoids+circles drawn in the optimized version probably make it slower again, but the gain seems to outweight the loss.
Btw: By now, in my fork on git-hub, what I did is split into separate commits, each of which having a (hopefully) helpful explanation.
Best,
Immi
new.pdf
Description: application/download
old.pdf
Description: application/download
test.xoj
Description: application/xoj
------------------------------------------------------------------------------
_______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
