On Mar 18, 2015, at 9:57 AM, Richard Hipp <d...@sqlite.org> wrote:
>
> * <canvas> is limited in size to 32768 pixels, while graphs
> sometimes approach one million pixels.
I assume you wrote this before seeing my
<td>
<canvas>
</td>
concept. 32 kpx divided by about 20 px per line means you’d need a checkin
comment about 1,600 lines long to exceed the limits of <canvas>.
> * PNG and SVN are unable to change dynamically in response to
> browser window resize events.
The more I think about the PNG option, the less I like it anyway. I only
mentioned it as an option to placate those who think it is reasonable to limit
web apps in 2015 to the capabilities of 1995 style browsers.
As I said in the original post, we do have dynamic PNG generation code in our
main web app, but it dates to about 2000, prior to the existence of <canvas>
and the widespread adoption of SVG in browsers. Our dynamic PNG generation
case is much simpler than Fossil’s timeline, so we have no real need to rewrite
it.
I’m not sure if SVG would show this scaling problem, too. It lets you specify
line thickness in px, but sometimes browsers scale absolute px values when
zooming. There’s also the HiDPI issue: a HiDPI/retina aware browser is going
to second-guess px values.
But, I think <canvas> actually matches Fossil’s needs best. It decouples the
drawing from the <table> layout code, and can be redrawn on window resize
events. That will solve the zoomed browser drawing problem, too.
You can handle the HiDPI issue in canvas by scaling absolute values by
window.devicePixelRatio.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
