Bommels05/Mozilla
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

removing old gfx2 code from the tree

Browse Source 
git-svn-id: svn://10.0.0.236/trunk@218648 18797224-902f-48f8-a5cc-f745e15eee43
This commit is contained in:
pavlov%pavlov.net
2007-01-19 01:18:22 +00:00
parent 43201df5bf
commit 58f2cac9dd
6 changed files with 0 additions and 1002 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
mozilla/gfx2/Makefile.in
View File

@@ -1,53 +0,0 @@
#
# ***** BEGIN LICENSE BLOCK *****
# Version: MPL 1.1/GPL 2.0/LGPL 2.1
#
# The contents of this file are subject to the Mozilla Public License Version
# 1.1 (the "License"); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
# http://www.mozilla.org/MPL/
#
# Software distributed under the License is distributed on an "AS IS" basis,
# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
# for the specific language governing rights and limitations under the
# License.
#
# The Original Code is mozilla.org code.
#
# The Initial Developer of the Original Code is
# Netscape Communications Corporation.
# Portions created by the Initial Developer are Copyright (C) 2000
# the Initial Developer. All Rights Reserved.
#
# Contributor(s):
# Stuart Parmenter <pavlov@netscape.com>
#
# Alternatively, the contents of this file may be used under the terms of
# either the GNU General Public License Version 2 or later (the "GPL"), or
# the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
# in which case the provisions of the GPL or the LGPL are applicable instead
# of those above. If you wish to allow use of your version of this file only
# under the terms of either the GPL or the LGPL, and not to allow others to
# use your version of this file under the terms of the MPL, indicate your
# decision by deleting the provisions above and replace them with the notice
# and other provisions required by the GPL or the LGPL. If you do not delete
# the provisions above, a recipient may use your version of this file under
# the terms of any one of the MPL, the GPL or the LGPL.
#
# ***** END LICENSE BLOCK *****
DEPTH = ..
topsrcdir = @top_srcdir@
srcdir = @srcdir@
VPATH = @srcdir@
include $(DEPTH)/config/autoconf.mk
DIRS = public src tmp
#ifdef ENABLE_TESTS
#DIRS += tests
#endif
include $(topsrcdir)/config/rules.mk

14
mozilla/gfx2/doxygen.h
View File

@@ -1,14 +0,0 @@
/**
* @mainpage gfx2 documentation
*
* @subsection proposal GFX2 Proposal
* @htmlonly
* <a href="proposal.html">Proposal</a>
* @endhtmlonly
*
* @subsection timeline GFX2 Timeline
* @htmlonly
* <a href="timeline.html">Timeline</a>
* @endhtmlonly
*
*/

44
mozilla/gfx2/makefile.win
View File

@@ -1,44 +0,0 @@
#!nmake
#
# ***** BEGIN LICENSE BLOCK *****
# Version: MPL 1.1/GPL 2.0/LGPL 2.1
#
# The contents of this file are subject to the Mozilla Public License Version
# 1.1 (the "License"); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
# http://www.mozilla.org/MPL/
#
# Software distributed under the License is distributed on an "AS IS" basis,
# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
# for the specific language governing rights and limitations under the
# License.
#
# The Original Code is mozilla.org code.
#
# The Initial Developer of the Original Code is
# Netscape Communications Corporation.
# Portions created by the Initial Developer are Copyright (C) 2000
# the Initial Developer. All Rights Reserved.
#
# Contributor(s):
# Stuart Parmenter <pavlov@netscape.com>
#
# Alternatively, the contents of this file may be used under the terms of
# either the GNU General Public License Version 2 or later (the "GPL"), or
# the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
# in which case the provisions of the GPL or the LGPL are applicable instead
# of those above. If you wish to allow use of your version of this file only
# under the terms of either the GPL or the LGPL, and not to allow others to
# use your version of this file under the terms of the MPL, indicate your
# decision by deleting the provisions above and replace them with the notice
# and other provisions required by the GPL or the LGPL. If you do not delete
# the provisions above, a recipient may use your version of this file under
# the terms of any one of the MPL, the GPL or the LGPL.
#
# ***** END LICENSE BLOCK *****
DEPTH = ..
DIRS = public src
include <$(DEPTH)\config\rules.mak>

382
mozilla/gfx2/proposal.html
View File

@@ -1,382 +0,0 @@
<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>

232
mozilla/gfx2/proposal.old.html
View File

@@ -1,232 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html lang="en-US">
<head>
<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; }
*/
/* 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><h1>GFX2: widget/gfx rewrite</h1>
<div>"GFX2" provides what is currently provided by both gfx and widget (including timers).</div>
</div>
<div><h1>Problems:</h1>
<div><h2>Graphics</h2>
<div>Windows specific apis, hacks, etc. <strong>(make this better)</strong></div>
<div><h3>Performance</h3>
<div>Due to some of the current APIs, it is hard for us to use the operating system for many things that it can be used for.</div>
<div><h4>Blending/Alpha compositing</h4>
<div><strong>???</strong></div>
</div>
<div><h4>Clipping</h4>
<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></div>
</div>
<div><h4>Images</h4>
<div><h5>Memory size</h5>
<div>Currently, we hold around 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 around.</div>
</div>
<div><h5>Scaling and dithering</h5>
<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>
</div>
<div><h5>Gamma</h5>
<div><strong>??</strong></div>
</div>
</div>
</div>
<div><h3>twips</h3>
<div>twips are the devices independent units that we use so that printing, etc can print and look the same, but they are not needed and cause performance hits due to constant float to integer conversions and back. They also provide confusion with some APIs taking twips and others pixels.</div>
</div>
<div><h3>SVG (scaleable vector graphics)</h3>
<div>The current graphics APIs that we have do not provide support for rendering vector graphic. There is no clean way to add these drawing primitives to the current gfx APIs.</div>
</div>
</div>
<div><h2>Widgets</h2>
<div>Obsolete APIs (designed for when we had native widgets) <strong>(make this better)</strong></div>
<div><h3>Events</h3>
<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 sent events, this problem will continue. <strong>(make this better)</strong></div>
</div>
<div><h3>Native form controls</h3>
<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.</div>
</div>
</div>
</div>
<div><h1>Proposal:</h1>
<div><h2>Graphics</h2>
<div><h3>merge widget and gfx in to a single component</h3>
<div>Since both widget and gfx deal with the native OS, drawing, and events, there is no reason for them to be separate components.</div>
</div>
<div><h3>floating point pixel coordinate system</h3>
<div>Remove twips.</div>
<div>With the CPUs used in modern hardware, we can replace twips with floating point pixel based coordinates and dimensions. Using floating point will account for the rounding problems that using twips aims to fix as well as reduce the need to convert to and from twips constantly. 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>
</div>
<div><h3>SVG (scaleable vector graphics)</h3>
<div><h4>Interfaces</h4>
<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 implimentation is needed to do this.</div>
</div>
<div><h4>Cross-platform Solutions</h4>
<div><h5>Fonts</h5>
<div><a href="http://www.freetype.org/">FreeType</a> is a high-quality font rendering engine capible of rendering anti-aliased fonts as well as rotating them.<strong>(blah blah blah)</strong></div>
</div>
<div><h5>Drawing</h5>
<div><a href="http://www.artofcode.com/libart.html">libart</a> is a library designed to render curves, vectors, do alpha compositing, etc. Unfortunatly 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. <strong>(blah blah blah)</strong></div>
</div>
</div>
</div>
<div><h3>Clipping</h3>
<div><h4>Less of it</h4>
<div>Clipping should be done only when it is absolutly needed. <strong>(more stuff)</strong></div>
</div>
<div><h4>Mandatory vs. discretionary clip regions (potentially)</h4>
<div><strong>add some of the things roc and I have discussed.</strong></div>
</div>
</div>
<div><h3>Images</h3>
<div><h4>Imglib1.5</h4>
<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>
</div>
<div><h5>Scaling and dithering</h5>
<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 24bit image data.</div>
<div>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.</div>
<div>nsIDrawable provides separate methods for drawing an image and drawing a scaled image to avoid any confusion about how to draw an image.</div>
<div>Platforms that do not support scaling or dithering could probably port gdkrgb and/or gdk_pixbuf to their platform to provide these services in software for them.</div>
</div>
<div><h5>RGBA packed image data</h5>
<div><strong>???</strong></div>
</div>
<div><h5>Gamma</h5>
<div><strong>???</strong></div>
</div>
</div>
</div>
<div><h2>Widgets</h2>
<div><h3>Events</h3>
<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 due to this. A test listener suite should be made that validates a platform implementation to ensure that it meets the specification perfectly.</div>
</div>
<div><h3>Native form controls</h3>
<div>XBL can be used to do this work with less overhead and problems than using real native widgets.</div>
<div>Internet Explorer on widows does not use win32 native form controls.</div>
<div>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>
</div>
</div>
<div><h2>System services</h2>
<div><h3>Clipboard</h3>
<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>
</div>
<div><h3>Drag and Drop</h3>
<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>
</div>
<div><h3>File Picker</h3>
<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>
</div>
<div><h3>System look and feel</h3>
<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="class_nsISystemLook.html">nsISystemLook</a> interface that contains all of this information.</div>
</div>
</div>
<div><h2>Interfaces</h2>
<div><h3>Documentation</h3>
<div>The GFX2 interfaces are full documented using doxygen and JavaDoc style comments.</div>
<div>See <a href="annotated.html">the full list of interfaces and information</a>.</div>
</div>
</div>
<div><h2>Questions</h2>
<div><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>
</div>
<div><h3>Will GFX2 break existing platforms such as BeOS and OS/2?</h3>
<div><h4>No</h4>
<div>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>
</div>
</div>
<div><h3>Should GFX2 interfaces use XPCOM?</h3>
<div><h4>Pro</h4>
<div><h5>Scriptability</h5>
<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>
</div>
<div><h5>Run time switching</h5>
<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>
</div>
</div>
<div><h4>Con</h4>
<div><h5>Speed</h5>
<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>
</div>
</div>
<div><h4>Overall</h4>
<div><h5>Should we use it?</h5>
<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.</div>
<div>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>
</div>
</div>
</div>
<div><h3>Is GFX2 Y2K compliant?</h3>
<div>maybe</div>
</div>
</div>
</div>
<p>
comments/questions: email <a href="mailto:pavlov@netscape.com">Stuart Parmenter</a>
</p>
</body>
</html>

277
mozilla/gfx2/timeline.html
View File

@@ -1,277 +0,0 @@
<html>
<head>
<title>gfx2 timeline</title>
<style type="text/css">
body { color: black; background: white; }
h1 { background: black; color: white; padding: 0.2em 0.6em; letter-spacing: 0.1em; }
table { border-spacing: 0; }
td, th { vertical-align: top; text-align: left; }
th { font-size: 1.5em; border-bottom: solid; }
td { padding: 1em 1em 1em 0; border-bottom: solid thin; }
tbody.subsection > tr > td { border: none; }
tbody.subsection > tr:first-child > td { padding-bottom: 0.25em; }
tbody.subsection > tr + tr > td { padding: 0.25em 1em 0.25em 0; }
tbody.subsection > tr + tr > td:first-child { padding-left: 1em; }
tbody.subsection > tr:last-node > td { border-bottom: solid thin; padding-bottom: 1em; } /* moz only hack */
tr + tr th, tbody + tbody > tr:first-child > th { padding-top: 2em; }
ul { margin: 0; padding: 0; }
li { margin: 0 0 0 2em; }
.time { width: 10em; }
.footnote { font-size: 0.6em; vertical-align: text-top; }
.footnote:before { content: '['; }
.footnote:after { content: ']'; }
.status { display: block; }
.footnotes:before { display: block; content: 'Footnotes'; font-style: normal; font-size: 1.1em; }
.footnotes { font-size: 0.9em; margin: 2em 0 0 0; }
</style>
</head>
<body>
<h1>gfx2 timeline</h1>
<table>
<colgroup><colgroup><colgroup class="time">
<tbody>
<tr><th colspan="3">Stage 1</th></tr>
<tr>
<td>Additional review/planning</td>
<td>
<ul>
<li><a href="mailto:pavlov@netscape.com">Stuart Parmenter</a></li>
<li><a href="mailto:roc+@cs.cmu.edu">Robert O'Callahan</a></li>
<li><a href="mailto:alexl@redhat.com">Alex Larson</a></li>
<li><a href="mailto:kmcclusk@netscape.com">Kevin Mcclusky</a></li>
<li>anyone else</li>
</ul>
</td>
<td>2 weeks</td>
</tr>
<tr>
<td>Make changes to the tree to use new apis
<ul>
<li>removing twips</li>
<li>make things compile :-)</li>
</ul>
</td>
<td>
<ul>
<li><a href="mailto:pavlov@netscape.com">Stuart Parmenter</a></li>
<li>anyone else</li>
</ul>
</td>
<td>1 week <span class="footnote"><a href="#footnote1">1</a></span> <span class="status">(90% complete)</span></td>
</tr>
<tr>
<td>Debug and resolve problems in layout</td>
<td>
<ul>
<li><a href="mailto:pavlov@netscape.com">Stuart Parmenter</a></li>
<li><a href="mailto:kmcclusk@netscape.com">Kevin Mcclusky</a></li>
<li>etc</li>
<li>whoever else we need to help with changes to their code</li>
</ul>
</td>
<td>2 weeks <span class="footnote"><a href="#footnote1">1</a></span></td>
</tr>
</tbody>
<tbody class="subsection">
<tr>
<td colspan="3">Initial Platform Work</td>
</tr>
<tr>
<td>X Windows</td>
<td>
<ul>
<li><a href="mailto:pavlov@netscape.com">Stuart Parmenter</a></li>
<li>Blizzard</li>
</ul>
</td>
<td>3 weeks <span class="footnote"><a href="#footnote2">2</a></span> <span class="footnote"><a href="#footnote3">3</a></span></td>
</tr>
<tr>
<td>Microsoft Windows</td>
<td>
<ul>
<li><a href="mailto:kmcclusk@netscape.com">Kevin Mcclusky</a></li>
<li>????</li>
</ul>
</td>
<td>2 weeks <span class="footnote"><a href="#footnote3">3</a></span></td>
</tr>
<tr>
<td>Mac</td>
<td>
<ul>
<li>Saari?</li>
<li>Beard?</li>
<li>???????</li>
</ul>
</td>
<td>2 weeks <span class="footnote"><a href="#footnote3">3</a></span></td>
</tr>
<tr>
<td>Adapter Layer</td>
<td>
<ul>
<li>everyone</li>
</ul>
</td>
<td>2 weeks</td>
</tr>
</tbody>
<tbody>
<tr><th colspan="3">Stage 1.5</th></tr>
<tr>
<td>Land stage 1</td>
<td>
<ul>
<li>...</li>
</ul>
</td>
<td>1 week (merge, etc)</td>
</tr>
</tbody>
<tbody>
<tr><th colspan="3">Stage 2</th></tr>
<tr>
<td>Imglib 1.5 (or 2.0?)
<ul>
<li>32bit RGBA packed image data</li>
<li>Add scaling and dithering code to gfx2</li>
</ul>
</td>
<td>
<ul>
<li><a href="mailto:tor@cs.brown.edu">Tim Rowley</a></li>
<li><a href="mailto:pavlov@netscape.com">Stuart Parmenter</a></li>
<li>windows people</li>
<li>mac people</li>
</ul>
</td>
<td>unknown</td>
</tr>
</tbody>
<tbody>
<tr><th colspan="3">Stage 2.5</th></tr>
<tr>
<td>Land stage 2</td>
<td>
<ul>
<li>...</li>
</ul>
</td>
<td>unknown</td>
</tr>
</tbody>
<tbody>
<tr><th colspan="3">Stage 3</th></tr>
<tr>
<td>SVG</td>
<td>
<ul>
<li><a href="mailto:kmcclusk@netscape.com">Kevin Mcclusky</a></li>
<li><a href="mailto:pavlov@netscape.com">Stuart Parmenter</a></li>
<li><a href="mailto:alexl@redhat.com">Alex Larson</a></li>
<li>...?</li>
</ul>
</td>
<td>unknown (this is additional "new" work, and not required to replace gfx and widget)</td>
</tr>
</tbody>
<tbody>
<tr><th colspan="3">Stage 3.5</th></tr>
<tr>
<td>Land stage 3</td>
<td>
<ul>
<li>...?</li>
</ul>
</td>
<td>unknown</td>
</tr>
</tbody>
<tbody>
<tr><th colspan="3">Stage 4</th></tr>
<tr>
<td>Remove native scrollbars?</td>
<td>
<ul>
<li>Anyone</li>
</ul>
</td>
<td>1 day (once no one depends on them anymore)</td>
</tr>
</tbody>
<tbody>
<tr><th colspan="3">Stage 4.5</th></tr>
<tr>
<td>Land stage 4</td>
<td>
<ul>
<li>...?</li>
</ul>
</td>
<td>1 day</td>
</tr>
</tbody>
</table>
<p class="footnotes">
<a name="footnote1">1</a>: This assumes that no <em>major</em> changes come out of the additional review and planning.<br>
<a name="footnote2">2</a>: The basic code is 40% complete, however by removing GTK from the picture, the clipboard and drag and drop code will require some porting of code that is in GTK in to Mozilla which will take around 2 weeks.<br>
<a name="footnote3">3</a>: The Unix, Mac, and Windows code can be written in parallel.
</p>
</body>
</html>