Skip to content
Snippets Groups Projects
Commit c30f2e1a authored by edgrif's avatar edgrif
Browse files

replaced with shtml version

parent 1aaf56e9
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 0 additions and 108 deletions
doc/design_notes.html deleted 100755 → 0
+ 0
− 108
View file @ 1aaf56e9
<HTML>
<HEAD>
<TITLE>ZMap Design</TITLE>
</HEAD>
<BODY>
<blockquote>
<P>The purpose of this document is to be a repository for all aspects of the design
of ZMap.
<P>Pictures are allowed, just include them in the cvs directory.
<H1>Requirements, Wish Lists, Suggestions etc.</H1>
<H2>Requirements</H2>
<P>Record anything here that is essential to ZMap.
<H3>Mapping in the client</H3>
<P>We should strongly consider putting a modified (i.e. acedb-less SMap) into
the client, this would allow the client to map different sorts of data onto
its virtual sequence provided it had the initial mapping from the new data
to its own virtual sequence.
<P>This would be very powerful because it would mean the client could accept
data from many sources and map it as long as it had the extent of the data
in the virtual sequence.
<H3>How to indicate strand</H3>
<P>In acedb we have traditionally had the down strand to the right and the up strand
to the left of the scale, this has some advantages but could be augmented visually
with exons that had pointy bits to show their direction etc.
<P>We could go for everything being shown on one side of a scale but this seems
a bit retrograde to me, the display is actually something that marks the fmap
out from other viewers in a good way.
<H3>Richer glyph set</H3>
<P>We need a richer glyph set, perhaps with exon shapes that indicate direction and
other such stuff, e.g. how about indicating start/end_not_found etc.
<H2>Wish List</H2>
<P>Record anything here that you would like to be considered but is non-essential.
<ul>
<li>Allow user to interactively retitle a window, v. useful when there are lots
of fmap windows on a screen.
<li>Prevent users from zooming in/out to the point where the drawing code breaks, particularly
for zooming in where lines start to randomly appear/disappear.
</ul>
<H1>Design</H1>
<H2>Overview</H2>
<P>
<H2>Configuration Files</H2>
<P>If looks like the libgnome gnome-config calls will do this for us, see:
http://developer.gnome.org/doc/API/2.0/libgnome/libgnome-gnome-config.html
<H2>Gnome Canvas</H2>
<H3>Memory usage</H3>
<P>An experiment with creating rectangles in a gnome canvas showed that memory overhead
is quite high. The upshot is that each canvas_item rectangle costs about 2600 bytes, this
is probably because each one is represented by a GObject.
<P>You can see a plot of this data by running gnuplot and displaying the file
gnome_canvas_mem_usage from this docs directory.
<pre>&gt; gnuplot
gnuplot&gt; plot "gnome_canvas_mem_usage"
</pre>
<HR>
<ADDRESS><a href="mailto:edgrif@sanger.ac.uk">Ed Griffiths &lt;edgrif@sanger.ac.uk&gt;</a></ADDRESS>
<!-- hhmts start -->
Last modified: Wed Jan 21 17:42:50 GMT 2004
<!-- hhmts end -->
</BODY>
</HTML>
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment