HTML5 graphics: Canvas vs. SVG

I've asked this question to Timothy Jordan from google, he told me canvas is for interactive graphics while SVG otherwise.

I've been searching which of the two to use in my mobile app (using phonegap) and why ?
The first thing I noticed is that most common mobile browsers does not support SVG at all (eg. android < 3.x )
The second thing I noticed that they support canvas very well.

SVG is an xml graphical format, so you might use usual DOM manipulations, on the other hand, Canvas is a set of methods you call to draw things (works like this: clear, draw, clear, draw ...etc).

In short if you want to create both web and mobile apps and cares for browser compatibility you might consider some api like dojo.gfx, if you just want a rich mobile app then you go with canvas.


Comments

Post a Comment

Popular posts from this blog

How to defuse XZ Backdoor (or alike) in SSH Daemon

XZ Backdoor in SSH Background Someone planted a backdoor in XZ compression, which is believed to affect SSH. More details can be found. Although it was never shipped to production version of any distro. Even if you are using unaffected version I suggest you defuse any similar backdoors. https://www.openwall.com/lists/oss-security/2024/03/29/4 https://news.ycombinator.com/item?id=39865810 https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users The Kill Switch The backdoor has a kill switch, it does not activate if it detects that someone is observing it (debugger attached...etc). An easy way to defuse the backdoor is to just define TERM environment variable causing the backdoor to think it's being observed and it would disable itself hopefully this is not specific to this backdoor but any similar one.  mkdir /etc/systemd/system/sshd.service.d/ echo -e "[Service]\nEnvironment=TERM=xt...
Read more

Making minimal graphical operating system

Image
Back in my first days of Linux I had a bootable floppy disk with fully functional Linux distro (a kernel, a shell and busybox tools and lua scripting). Maybe that was not much, but it was less than 2MB and would work on an old 386 PC with 4MB of RAM. But shell is boring, graphical minimal Linux distros was several hundreds of mega bytes and need hundreds of MB of RAM. Embedded devices typically have a minimal Linux with busybox or alike running with no graphical interface but instead they have some sort of web interface exposed to some port. If you tried to run a minimal graphical Linux distro let's say XFCE on an embedded device (let's say a raspberry pi) you would notice that most of its limited resources are taken by Xorg the legacy graphical server. Introducing Wayland Wayland is a new different approach to graphical interface, instead of sending drawing instruction over a legacy protocol (with so many extensions) to a legacy daemon (with so many extensions) that ...
Read more

Bootstrapping Alpine Linux QCow2 image

Introduction Alpine Linux is a minimal distro with package manager ( APK ) that is based on busybox and musl library . Like the  CirrOS , it's very lightweight, but unlike it, it's full featured. In case you don't know me, my Linux distro of choice is Fedora/CentOS, in this post I'm going to bootstrap a QCow2 cloud image of Alpine Linux on my distro of choice. Using docker to bootstrap a working chroot Type mkdir alpine35-root docker run --rm -ti -v $PWD/alpine35-root:/data alpine:3.5 apk --arch x86_64 -X http://nl.alpinelinux.org/alpine/v3.5/main/ -U --allow-untrusted --root /data --initdb add alpine-base  and you should get a line like this OK: 6 MiB in 16 packages so now we have a working alpine chroot in the directory alpine35-root Creating Bootable QCoW2 Image Because I don't want to format my hard disk by mistake and because I know Murphy's law, I'll take those 6MB as tarball and continue on a VM. dd if=/d...
Read more