зеркало из https://github.com/mozilla/gecko-dev.git
383 строки
16 KiB
HTML
383 строки
16 KiB
HTML
|
<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>
|