GFX2: The widget/gfx redesign

Graphics

Widgets

• 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.

• Graphics

  • Performance
  • Alpha Channel Compositing
  • Clipping
    Potentially add mandatory vs. discretionary clip regions. Robert O'Calahan has been thinking about these issues. need info
  • Images
    • Memory Footprint
      ...?
    • Imglib1.5
      Tim Rowley 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.
    • Scaling and dithering
      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.
    • Image Color Correction
      We want to support this. needs investigation
  • Spacial Graphics Independence
    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), Scott Collins 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.
  • SVG (Scaleable Vector Graphics)
    • Interfaces
      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.

    • People
      Kevin McCluskey is on the SVG working group. need to get input from him
    • Cross-platform Solutions
      • Fonts
        FreeType is a high-quality font rendering engine capable of rendering anti-aliased fonts as well as rotating them where the OS is not sufficient.
      • Drawing
        libart 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. Alex Larson has worked on libart in the past and can provide assistance.

• Widgets

  • Events
    As part of GFX2, the events generated by the system will have to conform to a specification that will be written up by Stuart Parmenter, Tom Pixley, Chris Saari, 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.
  • Native Form Controls
    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.
  • UNIX Toolkit
    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.

• System Services

  • Clipboard
    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.
  • Drag and Drop
    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.
  • File Picker
    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.
  • System Look and Feel
    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 nsISystemLook interface that contains all of this information.

• The GFX2 interfaces are full documented using doxygen and JavaDoc style comments. See the full list of interfaces and information.

• Is GFX2 thread safe?

  The implementations are probably not, however an attempt has been made to make the interfaces reentrant (with noted exceptions such as nsIClipboard).

• Will GFX2 break existing platforms such as BeOS and OS/2?

  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.

• Should GFX2 interfaces use XPCOM?

  • Pro
    • Scriptability
      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.
    • Run Time Switching
      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.
  • Con
    • Speed
      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.
  • Overall
    • Should We Use XPCOM?
      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.
• Is GFX2 Y2K Compliant?
  Maybe.