[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

---------- Forwarded message ----------
From: Mario Steele <mario@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@gmail.com>
Cc: "Perl Mongers of Omaha, Nebraska USA" <omaha-pm@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: http://clab.ist.unomaha.edu/CLAB/index.php/Talk:RT386#Profiling

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 below:

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@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@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 _javascript_y (almost AJAXy) scroll bar
> to our tool:
>
> http://clab.ist.unomaha.edu/CLAB/index.php/RT386
>
> j
>
> _______________________________________________
> Omaha-pm mailing list
> Omaha-pm@pm.org
> http://mail.pm.org/mailman/listinfo/omaha-pm
>


--
Todd Christopher Hamilton
(402) 660-2787






--
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/