gecko-dev/gfx2/proposal.html

383 lines
16 KiB
HTML
Raw Normal View History

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.61 (Macintosh; I; PPC) [Netscape]">
<title>GFX2 Proposal</title>
<style type="text/css">
/* FONTS */
/* pavlov said no
body { font: 900 3em sans-serif; }
div { font-size: 0.8em; font-weight: lighter; }
div > div > div > div > div > div { font-size: 1em; }
h1, h2, h3, h4, h5, h6, p, ul, ol, li { font: inherit; }
*/
div.title { text-align: center; }
/* LAYOUT */
h1, h2, h3, h4, h5, h6, p, ul, ol, li { margin: 0; padding: 0; }
div { margin: 0.25em 0 0.5em 2em; }
/* DECORATION */
/* pavlov said no to this too * { border: solid 1px; } */
/* COLOUR */
body { background: white; color: black; }
strong { font-size: 0.7em; color: red; }
</style>
</head>
<body>
<div class="title">
<h1>GFX2: The widget/gfx redesign</h1>
"GFX2" provides what is currently provided by both gfx and widget (including timers).
</div>
<hr/>
<h2>Problems with the current implementations:</h2>
<div>
<h3>Graphics</h3>
<div><ul>
<li>Performance
<div><p>Due to some of the current APIs, it is hard for us to fully leverage an operating
system graphics capabilities. The advantage to using the OS facilities is that
they are often optimized for their specific processor and/or video hardware
architectures.</p>
<p>An example of this approach is the Apple Quartz graphics architecture which
provides the next generation graphics capabilities behind the Aqua user interface.
All of MacOS X's graphics APIs are accelerated for their Altivec/Velocity
engine enabled processors and push graphic operations to accelerated video
hardware whenever possible.</p></div>
</li>
<li>Alpha Channel Compositing
<div><ul>
<li>The current alpha blending code doesn't support all bitdepths.</li>
<li>We need a view for each alpha blended pixmap.<strong>??</strong></li>
<li>We cannot take advantage of any accelerated OS blending code.</li>
</ul></div>
</li>
<li>Clipping
<div>We currently do far too much clipping. This causes numerous performance problems,
especially on X11 based systems. Due to the way X works, changing the clip
region makes the X server have to flush its connections to make sure nothing
has changed since it received the clip region. <strong>(this isn't a completely
accurate description, change it)</strong>
<p>This should help Windows as well.</p>
</div>
</li>
<li>Images
<div><ul>
<li>Memory Footprint
<div>Currently, we keep at least two copies of the image data around in memory.
One compressed and one decompressed. As part of GFX2 and imagelib 1.5,we
hope to only hold a single copy of the image data in memory.</div>
</li>
<li>Scaling and Dithering
<div>Both image scaling and dithering currently is done in both imagelib and gfx
depending on your platform and the code path that layout uses to draw the
image. This causes confusion and does not allow the platform to optimize the
scaling and dithering operations.</div>
</li>
<li>Image Color Correction
<div>We don't have it today. Apple has been working on ColorSync integration that is not complete and doesn't
provide a solution for Linux and Windows. This prevented PNGs from being used in the modern 2 skin.</div>
</li>
</ul></div>
</li>
<li>Spacial Graphics Independence
<div>Twips are the device independent units that we theoretically use to achieve
WYSIWYG printing and cross display rendering. The disadvantage to the current
approach is that we have to convert from pixels to twips coming into the system,
and back again to pixels whenever we go out to the display device. This is a performance hit and
causes confusion in the code.</div>
</li>
<li>SVG (Scaleable Vector Graphics)
<div>The current graphics APIs that we have do not provide support for rendering
vector graphics. There is no clean way to add these drawing primitives
to the current gfx APIs. Scaled vector graphics operations also lend themselves
to hardware acceleration which any implementation cannot cleanly utilize
in an XP manor.</div>
</li>
</ul></div>
<h3>Widgets</h3>
<div>
Many of the APIs were designed for when we had native widgets.
<div><ul>
<li>Events
<div>The way operating systems handle events are often quite different. This
creates a problem with the current way we handle events. Engineers are
forced to spend large amounts of time tracking down bugs that are caused
by event ordering, and with no solid specification on how we should send
events, this problem will continue.</div>
</li>
<li>Native form controls
<div>There is good bit of code left in the current widget module that is no
longer used or needed. These interfaces and code should be removed. Should
the need for "native" form controls arise again, XBL should be able to
do the job of making native looking and feeling form controls or wrapping native
control implementations.</div>
</li>
<li>UNIX Toolkit
<div>The use of GTK introduces a little bit of extra memory footprint that is
no longer needed since we no longer use native widgets.</div>
</li>
</ul></div>
</div>
</div>
<hr/>
<h2>Proposal:</h2>
<div>
<ul>
<li>Merge widget (including timers) and gfx in to a single component
Since both widget and gfx deal with the native OS, drawing, and events,
there is no reason for them to be separate components. This will reduce
cross library calls in critical code paths and centralize native code.</li>
<li><h3>Graphics</h3>
<div><ul>
<li>Performance</li>
<li>Alpha Channel Compositing</li>
<li>Clipping
<div>Potentially add mandatory vs. discretionary clip regions.
Robert O'Calahan has been thinking about these issues. <strong>need info</strong></div>
</li>
<li>Images
<div><ul>
<li>Memory Footprint
<div><strong>...?</strong></div>
</li>
<li>Imglib1.5
<div><a href="mailto:tor@cs.brown.edu">Tim Rowley</a> is working on imglib 1.5.
The new image library in conjunction with the new imaging APIs in GFX2,
we should be able to reduce the number of copies of the image data to one.</div>
</li>
<li>Scaling and dithering
<div>As part of imglib 1.5, Tim will be removing imglib's image scaling and
dithering code. All image data will come from imglib as 32bit RGBA packed image data.
Each platform's GFX2 implementation may decide what bit depth to cache the
data in. Each GFX2 implementation must be able to scale an image using either native
system APIs or another means. Having each platform do this allows platforms
that do support scaling and/or dithering to take advantage of any hardware
optimizations that they can. nsIDrawable provides separate methods for drawing
an image and drawing a scaled image to avoid any confusion about how to
draw an image. Platforms that do not support scaling or dithering could port gdkrgb
and/or gdk_pixbuf to their platform to provide these
services in software for them.</div>
</li>
<li>Image Color Correction
<div>We want to support this. <strong>needs investigation</strong></div>
</li>
</ul></div>
</li>
<li>Spacial Graphics Independence
<div>Remove twips from the common code paths. With the CPUs used in modern hardware,
we can replace twips with floating point pixel based coordinates and dimensions. Using
floating point aims to reduce the potential rounding errors to one final coordinate
system to device conversion. For systems without a FPU (StrongArm, etc),
<a href="mailto:scc@mozilla.org">Scott Collins</a> has volunteered to write a fixed-point
class that we could simply plug in instead of floating points. Devices such as printers
would be able to use a transformation matrix to scale the pixel values so that
they match the DPI that you are printing to.</div>
</li>
<li>SVG (Scaleable Vector Graphics)
<div><ul>
<li>Interfaces
<div>SVG related drawing methods will be put on their own interface, something
like nsIVectorDrawable, which you can QI to and from an nsIDrawable. An
XP implementation that does its own rasterization and delegates everything
else to an underlying GFX implementation is needed to do this.</p>
</div>
</li>
<li>People
<div><a href="mailto:kmcclusk@netscape.com">Kevin McCluskey</a> is on the SVG working group.
<strong>need to get input from him</strong>
</div>
</li>
<li>Cross-platform Solutions
<div><ul>
<li>Fonts
<div><a href="http://www.freetype.org/">FreeType</a> is a high-quality font
rendering engine capable of rendering anti-aliased fonts as well as rotating
them where the OS is not sufficient.</div>
</li>
<li>Drawing
<div><a href="http://www.artofcode.com/libart.html">libart</a> is a library
designed to render curves, vectors, do alpha compositing, etc. Unfortunately
the author no longer has much time to work on it, so we would need someone
here to work on it and integrate it with our system, again where OS facilities
are not present or appropriate. <a href="mailto:alexl@redhat.com">Alex Larson</a> has worked on libart
in the past and can provide assistance.</div>
</li>
</ul></div>
</li>
</ul></div>
</li>
</ul></div>
</li>
<li><h3>Widgets</h3>
<div><ul>
<li>Events
<div>As part of GFX2, the events generated by the system will have to conform
to a specification that will be written up by <a href="mailto:pavlov@netscape.com">Stuart
Parmenter</a>, <a href="mailto:joki@netscape.com">Tom Pixley</a>, <a href="mailto:saari@netscape.com">Chris
Saari</a>, and others. This will ensure that all events received by listeners
to windows will receive them in a cross platform manner and help to remove
numerous problems that we currently have in this area. A test listener suite
should be made that validates a platform implementation to ensure that
it meets the specification perfectly.</div>
</li>
<li>Native Form Controls
<div>XBL can be used to do this work with less overhead and problems than using
real native widgets. For example, Internet Explorer on Windows does not use win32 native
form controls. Currently there is no need for native form controls, but
this could change. The APIs have been designed so that native form controls
and other native widgets may be added later without disrupting the current
set of GFX2 APIs.</div>
</li>
<li>UNIX Toolkit
<div>Since we no longer need native widgets, we can remove the dependencies on
Unix build dependencies on GTK which will reduce build dependencies and reduce some
memory footprint by only depending on Xlib.</div>
</li>
</ul></div>
</li>
<li><h3>System Services</h3>
<div><ul>
<li>Clipboard
<div>The clipboard interfaces remain mostly the same. There has been discussion
about making the getData methods asynchronous, but nothing has been finalized
at this time.</div>
</li>
<li>Drag and Drop
<div>At the time of this writing, the drag and drop interfaces have not been
looked at, but they are not expected to change a great deal.</div>
</li>
<li>File Picker
<div>The file picker interface has not changed. There has been talk of changing
the way filtering works a bit, but this has not been finalized at this
time.</div>
</li>
<li>System Look and Feel
<div>Currently, we have two interfaces, nsILookAndFeel and nsIDeviceContext
that can both be asked for information about CSS fonts, colors, etc. These
have been merged in to a single <a href="http://www.pavlov.net/gfx2/class_nsISystemLook.html">nsISystemLook</a>
interface that contains all of this information.</div>
</li>
</ul></div>
</li>
</ul>
</div>
<hr/>
<h2>Documentation</h2>
<div>
<ul>
<li>The GFX2 interfaces are full documented using doxygen and JavaDoc style comments.
See <a href="http://www.pavlov.net/gfx2/annotated.html">the full list of
interfaces and information</a>.
</li>
</ul>
</div>
<hr/>
<h2>Questions</h2>
<div>
<ul>
<li><h3>Is GFX2 thread safe?</h3>
<div>The implementations are probably not, however an attempt has been made to make
the interfaces reentrant (with noted exceptions such as nsIClipboard). </div>
</li>
<li><h3>Will GFX2 break existing platforms such as BeOS and OS/2?</h3>
<div>No, an adaptation layer will be made that will convert calls made to the new GFX2
APIs in to the old APIs allowing current implementations to continue working
until they are ported.</div>
</li>
<li><h3>Should GFX2 interfaces use XPCOM?</h3>
<div>
<ul>
<li>Pro
<div><ul>
<li>Scriptability
<div>Having the interfaces be scriptable makes writing test cases for them much
easier. To help people writing new implementations and porting to new platforms,
having a test suite that tests all of their code will make a huge difference.
We can also use scriptability to do things like check event ordering from
windows, etc.</div>
</li>
<li>Run Time Switching
<div>Having GFX2 use XPCOM interfaces allows us to change toolkits at runtime.
This may not seem like a big win, but imagine us shipping an Xlib based browser
for Unix systems and someone wants to run using NanoX. They could use our Unix
builds and simply switch out their GFX2 implementation for their own without
having to build the whole product specifically for them.</div>
</li>
</ul></div>
</li>
<li>Con
<div><ul>
<li>Speed
<div>Due to the cost of virtual functions, it will be a bit slower than if we did
not use XPCOM for GFX2. If the GFX2 library was linked to other libraries,
the compiler/linker might be able to further optimize the code paths.</div>
</li>
</ul></div>
</li>
<li>Overall
<div><ul>
<li>Should We Use XPCOM?
<div>After spending time looking at the usage patterns of GFX through layout, using
XPCOM should provide only an insignificant speed hit, while providing us with
scriptability and run time switching of implementations. Time would be better
spent removing XPCOM interfaces by focusing on interfaces such as nsISupportsArray
that are used constantly throughout the entire code base.</div>
</li>
</ul></div>
</li>
</ul>
</div>
</li>
<li>Is GFX2 Y2K Compliant?
<div>Maybe.</div>
</li>
</ul>
</div>
<hr/>
<p>comments/questions: email <a href="mailto:pavlov@netscape.com">Stuart Parmenter</a></p>
</body>
</html>