Changes from V2.x to V3.0 - Revision history

Inmarket: /* The New GDISP API */

2018-03-10T12:25:22Z

‎The New GDISP API

Inmarket: /* The New GDISP API */

2018-03-10T12:24:22Z

‎The New GDISP API

Inmarket: /* New Driver Format */

2018-02-24T08:01:34Z

‎New Driver Format

Inmarket: /* The New GDISP API */

2018-02-24T07:57:06Z

‎The New GDISP API

Inmarket: /* The New GDISP API */

2018-02-24T07:55:41Z

‎The New GDISP API

Inmarket: /* Types, Constants and Configuration Options */

2018-02-24T07:54:36Z

‎Types, Constants and Configuration Options

Inmarket: /* Single-File-Make */

2018-02-24T07:53:20Z

‎Single-File-Make

Inmarket at 07:52, 24 February 2018

2018-02-24T07:52:05Z

Inmarket at 06:34, 24 February 2018

2018-02-24T06:34:51Z

Inmarket at 06:14, 24 February 2018

2018-02-24T06:14:48Z

@@ Line 32: / Line 32: @@
 New Functionality:
-* New alpha pixel color formats are now supported. GDISP blending functions have been updated to match.
+* New alpha pixel color formats are now supported. GDISP color blending functions have been updated to match.
 * More accurate color conversion is available between pixel formats
 * Text drawing in other orientations is now available

@@ Line 41: / Line 41: @@
 Changes:
-* The predefined colors GFXBLACK, GFXWHITE, GFXRED etc replace the old color definitions Black, White, Red etc.
+* The predefined colors GFX_BLACK, GFX_WHITE, GFX_RED etc replace the old color definitions Black, White, Red etc.
 * Rounded boxes now require the new configuration option GDISP_NEED_ROUNDBOX.
 * Thick lines now require the new configuration option GDISP_NEED_THICKLINES.

@@ Line 69: / Line 69: @@
 == New Driver Format ==
-All uGFX drivers now use a new internal API and have been rewritten. As they are now included as part of the uGFX compile, drivers are not allowed to have symbol conflicts with any other driver in the system. Whilst this is not a huge issue for the drivers themselves (as they are all rewritten), this requirement also extends to the board files to interface them with actual hardware. This means that all board files will need to be rewritten. GDISP drivers are also structured differently and have new entry points in order to support the new GDISP API capabilities.
+All uGFX drivers now use a new internal API and have been rewritten. As they are now included as part of the uGFX compile, drivers are not allowed to have symbol conflicts with any other driver in the system. Whilst this is not a huge issue for the drivers themselves (as they are all rewritten for you already in the repository), this requirement also extends to the board files to interface them with actual hardware. This means that all board files will need to be rewritten. GDISP drivers are also structured differently and have new entry points in order to support the new GDISP API capabilities.
 While all board files will need to be rewritten, the new GBUS module will make that process much simpler. Most board interface files will now be much simpler.

@@ Line 35: / Line 35: @@
 * More accurate color conversion is available between pixel formats
 * Text drawing in other orientations is now available
-* All displays can be rotated whether or not the driver supports it. Where the driver doesn't support it directly the GDISP API performs the necessary rotations on the drawing operations. Also supported are new partial orientations such as X axis mirroring.
+* All displays can be rotated whether or not the driver supports it. Where the driver doesn't support it directly, the GDISP API performs the necessary rotations on the drawing operations although this may in some cases reduce drawing speed or require extra RAM buffers. Also supported are new partial orientations such as X axis mirroring.
 * All drawing now occurs on a single "canvas" rather than on a specific display device. This means that display operations are much more clearly separated from drawing operations. See the multiple display section for more details.
 * Flushing of drawing operations to the display can now be much more precisely controlled by the application.

@@ Line 32: / Line 32: @@
 New Functionality:
-* New pixel color supports support Alpha channels. GDISP blending functions have been updated to match.
+* New alpha pixel color formats are now supported. GDISP blending functions have been updated to match.
 * More accurate color conversion is available between pixel formats
 * Text drawing in other orientations is now available

@@ Line 19: / Line 19: @@
 GOS:
-* The configuration option GFX_OS_CALL_UGFXMAIN now defaults to GFXON if GFX_COMPAT_V2 is not set.
+* The configuration option GFX_OS_CALL_UGFXMAIN now defaults to GFXON if GFX_COMPAT_V2 is turned off.
 * Individual GFX_USE_OS_xxx configuration options are replaced by GFX_OS=GFX_OS_xxx. GFX_COMPAT_V2 allows the old configuration options to still be used.
 * The configuration option GFX_OS_EXTRA_INIT_FUNCTION has been renamed to GFX_OS_POST_INIT_FUNCTION

@@ Line 9: / Line 9: @@
 == Single-File-Make ==
-The single-file-make build mechanism now works with all uGFX features. This will provide greater compatibility with systems such as Arduino and other IDE's. Even drivers can be included in the single-file-make so it is only necessary to include a single source file into your project to include all of uGFX. The original makefile build option is still supported and will work unchanged.
+The single-file-make build mechanism now works with all uGFX features (including pixmaps). This will provide greater compatibility with systems such as Arduino and other IDE's. Even drivers can be included in the single-file-make so it is only necessary to include a single source file into your project to include all of uGFX. The original makefile build option is still supported and will work unchanged.
 == Types, Constants and Configuration Options ==

@@ Line 1: / Line 1: @@
-There are many major changes from uGFX V2.x to V3.0. While we have tried to maintain compatibility for most uGFX V2 applications there are some areas that will require re-writing.
+There are many major changes from uGFX V2.x to V3.0. While we have tried to maintain compatibility for most uGFX V2 applications there are some areas that will require re-writing. Below is a short summary of the changes. Much more detail will be provided as the V3.0 release comes closer.
-−
 == Compatibility ==
-The configuration option GFX_COMPAT_V2 is now defined that allows most V2.x code to compile unchanged. It is turned on by default.
+The configuration option GFX_COMPAT_V2 is now defined that allows most V2.x application code to compile unchanged. It is turned on by default (at least until V3.1). The sections below will talk about where specific items of compatibility has changed.
-More details to come
+A separate configuration option GFX_COMPAT_OLDCOLORS has also been created that controls the old uGFX color names. It also is turned on by default. The reason that this is separate from GFX_COMPAT_V2 is that for some operating systems it may be useful to turn off the old color definitions to prevent symbol conflicts even though you still want V2.x API compatibility.
 == Single-File-Make ==
-The single-file-make build mechanism now works with all uGFX features.
+The single-file-make build mechanism now works with all uGFX features. This will provide greater compatibility with systems such as Arduino and other IDE's. Even drivers can be included in the single-file-make so it is only necessary to include a single source file into your project to include all of uGFX. The original makefile build option is still supported and will work unchanged.
-More details to come
+== Types, Constants and Configuration Options ==
-== Type and Constant Changes ==
+General:
-Many types and constants have been renamed to prevent conflicts with other library, operating systems or other code.
+* GFXON and GFXOFF replace TRUE/FALSE for configuration options
-More details to come
+GOS:
 == The New GDISP API ==
-The GDISP API has been significantly changed.
+The GDISP API has been significantly changed. There are many new types and new functionality is available. See the new GDISP API documentation for more details (when it is available).
-More details to come
+New Functionality:
 == Multiple Display Support ==
-Multiple display support now works very differently.
+Multiple display support now works very differently. Instead of having to specify the display device on every drawing operation, now every drawing operation occurs on a virtual "canvas". Displays now overlap a portion of the virtual canvas. This allows some interesting capabilities.
-More details to come
+Case Study 1: Displays can be set to be side-by-side on the virtual canvas and drawing operations can span both display devices. This is similar to the way desktop operating systems handle multiple displays.
 == Adding Drivers To Your Build ==
-All drivers are now included using configuration options rather than by linking.
+All drivers are now included using configuration options rather than by linking them. This makes drivers much easier to include and build into projects. Unfortunately this means that all uGFX drivers have had to be rewritten and the interface has changed. This means that existing V2.x projects will need to be updated to include the configuration options for the drivers into the gfxconf.h file (or into your makefile C pre-processor symbols). It also means that most V2.x board files will need to be rewritten.
-−
-More details to come
 == New Driver Format ==
-All uGFX drivers now use a new internal API and have been rewritten.
+All uGFX drivers now use a new internal API and have been rewritten. As they are now included as part of the uGFX compile, drivers are not allowed to have symbol conflicts with any other driver in the system. Whilst this is not a huge issue for the drivers themselves (as they are all rewritten), this requirement also extends to the board files to interface them with actual hardware. This means that all board files will need to be rewritten. GDISP drivers are also structured differently and have new entry points in order to support the new GDISP API capabilities.
-More details to come
+While all board files will need to be rewritten, the new GBUS module will make that process much simpler. Most board interface files will now be much simpler.
 == The New GBUS Module ==
-Many hardware interface details that needed to be written explicitly into every driver board file are now handled by a new GBUS module.
+Many hardware interface details that needed to be written explicitly into every driver board file are now handled by a new GBUS module. A GBus driver provides a bus type interface to a hardware device. For example, a GBUS driver will exist for:
-More details to come
+Generally the only thing required to use a GBUS is to add the required GBUS driver in your configuration options and then initialise it with the specific CPU pins you want it to use in your display driver board file. This is much simpler than the old way where every driver board file needed to write the full hardware interface code which was often CPU and operating system specific.
 == New Trig Functions ==
 There are new triginomic functions that are significantly faster and more accurate than the old functions in GMISC.
 More details to come

← Older revision		Revision as of 06:34, 24 February 2018
Line 46:		Line 46:

	More details to come		More details to come
		+
		+	== Changes V3.1 and beyond ==
		+	* GWIN event update
		+	* GWIN window manager