On 3/18/15, Warren Young <w...@etr-usa.com> wrote: > I think you can just piece the graph together one row at a time. > HTML has several facilities for stretching graphic elements over the width > or height of a <td>, for example. > > Pseudocode: > > <td style=“background-image:url(‘row3523.png’); height: 100%” > valign=top align=center> > <img src=“box.png” onclick=“javascript:toggleSelection(this)"><br> > <img src=“arrowhead.png”> > </td> > > The row PNG would have the lines, and the box and arrowhead PNGs would > overlay it, hiding the fact that the line extends underneath.
For a 1000-check-in graph, how many PNGs are required? How many server round-trips is that? Or does it use the <img src="data:image/gif;base64,R0l...."> in-line image trick? In that case, how many GIFs does the server have to compute in order to render the timeline, and how long will that take on the server side? For all its faults, the current timeline mechanism works with a single HTTP request, has all content in a single HTML file, and is computed quickly and efficiently on the server side. > >>> 3. Generate the timeline via <canvas>. >> >> That also requires JS, no? > > Yes. If you went this route, I think you’d want to let the browser lay out > the <table>, then go in and draw each <td><canvas id=“row3987”></td> cell > one at a time. > >> the canvas is limited in size to 32768 pixels high > > Just so it’s clear, a <canvas>-per-<td> model makes that limit irrelevant. > That could be done. There are a few disadvantages though: (1) No longer works on browsers that lack <canvas> support. (That is less and less of a problem with each passing year - though it was a significant problem when Fossil was much younger.) (2) It is likely much more complicated than the one-big-graph approach. Currently, of there is a line from the 289th entry up to the 41st entry of the graph, that is a single entry in a table. But with separate canvas, apparently that line now requires entries in 249 different canvas definition tables? Either that, or somehow 249 different canvas renderings need to somehow find out about that one single entry in the global table. (3) The click-two-nodes-to-diff feature might be more difficult to implement. I'm unclear on this. Can events be added to a <canvas> that fire when a click occurs on a specific element? (4) This is basically a complete top-to-bottom redesign and rewrite of the timeline graph. One wonders if that effort might not be more profitably applied in other areas. The multiple canvas approach does have the advantage that it allows the use of curved and angled lines, whereas the current scheme requires a strict Manhattan geometry. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
