[Omaha.pm] Fwd: Fishing for GUI ideas...

Mario Steele mario at ruby-im.net
Wed Dec 3 05:35:42 PST 2008

Resent to the email list, since my "approval" wasn't completed at time of

---------- Forwarded message ----------
From: Mario Steele <mario at ruby-im.net>
Date: Wed, Dec 3, 2008 at 7:33 AM
Subject: Re: [Omaha.pm] Fishing for GUI ideas...
To: Todd Christopher Hamilton <netarttodd at gmail.com>
Cc: "Perl Mongers of Omaha, Nebraska USA" <omaha-pm at pm.org>

We run into a similar problem as we have right now, and why our current
method is static.  We have 5 different strains in which we need to convert
over into usable data.  Each strain has different set of data, some similar,
some not.  We're looking specifically for the mutations, but also for
markers of where the strain is found against our base comparison strain.

Currently, running out system as it is, the time it takes to generate the
output, is quite long, see:

The first test, is with a speed hack we had, that only loaded 1 strain of
data into the mixer, and generated only a snipplet of the genetic code, that
we could use for comparison of the design of the current output.  EG to give
us the best results, without running the same generation over and over and
over again, awaiting the length that the second part gives us.  Which, you
can see from the second set of test results, how long it takes to render 5
strains of data, into usable HTML format.

Also, as a side note, I sent this in a previous email, but was not
subscribed to the PM Email list, so I'm re-posting it here, to save space.

SVG would never, ever hold up to the rendering of the millions of base pairs
that are generated from the blast output.  I've looked at that as a
possibility for graphical representation, and just the shear amount of
generated data from both blast, and our own HTML output is demonstrated

blast_output size: 38m (All 5 strains blasted)
html size: 15 megs (give or take a few kilobytes for svn repo data, and
images used in my tool you listed below)

SVG would have a literal field day trying to load that much data up in the
scalable method, to zoom into the individual amplicons of the DNA Strand,
not counting all 5 that we are looking at.

On Wed, Dec 3, 2008 at 7:25 AM, Todd Christopher Hamilton <
netarttodd at gmail.com> wrote:

> xml is a great idea. I agree it might be to much to render but...what
> if you approached it like a large table.  the million row table
> problem has (AFAICT) has been solved with the concept of pageing.
> paging like displaying only 50 rows of you million row table.
> what if you took a similar approach with your svg? each zoom level
> displays only what you need.  new zoom requests (ajax) make a new
> query in the background.
> On 12/3/08, Jay Hannah <jay at jays.net> wrote:
> > On Dec 3, 2008, at 5:41 AM, Rob Townley wrote:
> >> Viral, Bacterial and ¿ribosomal? dna are usually in a circle.
> >> Normal human, but not mitochondrial DNA is a line.
> >> When i did research, most molecular biologists were only interested in
> >> circular dna because anything else was too big.  Of course the human
> >> genetic code has been broken since then.  It may not matter at all to
> >> your users...
> >
> > Ya. Whether or not they were looking at circular DNA our GUI would
> > flatten it (as many tools do).
> >
> >> When i taught C++, a geneticist and i toyed with a circular rna
> >> explorer like interface using a cross platform gui toolkit application
> >> for the Mac and Windows.
> >
> > Oh? Did it survive? What's the name of that project?
> >
> >> On a tangent, i was wondering if svg could make it easier to do a
> >> circle.   Scalable Vector Graphics defined in XML, maybe too much
> >> data.
> >> Or, using svg to make a line like interface similar to a disk
> >> defragging gui.
> >
> > Well, sidestepping the whole circular thing is my plan, so I don't
> > have to deal with it. I'd be very impressed if any SVG renderer could
> > scale up to thousands of base pairs without choking horribly.  :)
> >
> > Status update: Mario added an Javascripty (almost AJAXy) scroll bar
> > to our tool:
> >
> > http://clab.ist.unomaha.edu/CLAB/index.php/RT386
> >
> > j
> >
> > _______________________________________________
> > Omaha-pm mailing list
> > Omaha-pm at pm.org
> > http://mail.pm.org/mailman/listinfo/omaha-pm
> >
> --
> Todd Christopher Hamilton
> (402) 660-2787

Mario Steele

Mario Steele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/omaha-pm/attachments/20081203/4b941fc7/attachment.html>

More information about the Omaha-pm mailing list