The two most significant changes in the CChartViewer are:

High DPI support
===========

We need to auto-detect whether the application is running in high DPI mode. Apart from drawing the chart in high DPI, we also need to map the MFC mouse and display coordinates to the chart coordinates. The custom mouse cursors (like the zoom in cursor) needs to be multi-resolution. Instead of hard coded the cursor file (*.cur) data in the CChartViewer, we now put the cursors as resources in the chartdir70.dll.

We use the standard Win32 API LoadCursorA to load the cursor, because it can automatically select the correct mouse cursor resolution to use. That API expects a "handle" to the executable or DLL that contains the resource. The "getResourceLoader" simply returns the handle of the DLL.

After we implement this, we found that Qt does not support cursor file (*.cur)  at all. Instead it uses PNG images as cursors. So there is an alternative implementation in Qt that uses ChartDirector to draw the cursor PNG image directly and no resource is used. (We cannot use this method in MFC, as MFC does not support using PNG images as cursors.)

If the wxWidgets can use PNG images as cursors (or any image type that ChartDirector can generate), you may use the QASE_CursorManager in qchartviewer.cpp. Personally, I like this implementation better as it does not depend on resources.

CDML Tooltip support
=============

As we need to support transparency and flicker free movement of the tooltip, the implementation is a little bit complicated.

The "dynamic" is an internal undocumented flag. It means the tooltip can change as the mouse moves.

Normally, a hot spot is a region. For example, a bar in a bar chart can be a hot spot. There is a tooltip for the hot spot. The tooltip is not expected to change even if the mouse move as long as the mouse remain on the bar.

For a contour chart, there entire chart is a single continuous surface. The (x, y, z) value of the contour chart can change from pixel to pixel. In previous version of ChartDirector, the contour chart does not support tooltip. In ChartDirector 7, it is implemented as a "dynamic" tooltip that can change from pixel to pixel. The code in CChartViewer can detect if a hot spot is "dynamic". If it is, the CChartViewer will need to get an updated tooltip every time the mouse move.

To test high DPI on Windows, you just need to go to Settings/System/Display, and change the scale factor of your monitor from 100% to 150% (or some other scale factor).

The BaseChart or DrawArea do not use GUI. They always report the size they are configued. For example, if the code sets the size to 200 x 100, it will report its size as 200 x 100, irrespective of what is the DPI of the monitor.

The chart or DrawArea size should be as if the monitor is 96dpi. When the program is run, the control will cause the actual size to change to match the DPI setting of the monitor. The mechanism is implemented in the CChartViewer and QChartViewer controls. In our sample code, all the sizes are hard coded, and they can be used on monitors of different DPIs without modification.

The font size in points will always be converted to pixel size with 1 point = 1.333 pixel (which is 96 dpi). Note that the pixel is the so called "logical pixel". It is not the actual pixel unit on the monitor.

The DPI is managed by the control - the CChartViewer and QChartViewer in our code. If the control detects that the application is high DPI aware, it will use setOutputOptions to set a scale factor before calling makeChart to obtain the chart image. In this way, the DrawArea or BaseChart will produce a resized image. You can obtain the actual size by examining that output image. For example, if a scale factor of 150% is used, the actual image produced will be 300 x 150, but the DrawArea will still report 200 x 100.

If it only happens for translucent tooltip, one possibility is the alpha type. May be try to use "alpha=1" to see if it makes any difference.

I cannot think of a reason why non-transparent tooltip can have a different color.

Is it possible to save the screenshot in PNG?

If the BMP is using "pre-multiplied alpha" (alpha=3), but the way the tooltip is rendered expects "non-pre-multiplied alpha" (alpha=1), the translucent part will look darker than expected. If I know the pixels accurately, I can compute to see if check this can explain the problem.

To check if the tooltip itself is really too dark, after c->makeChart(Chart::BMP);, please add a line c->makeChart("c:pathtomytooltip.png");. This saves the same tooltip image in PNG format. We can examine the file to see if the tooltip is correct.

Transparency is not standardized in BMP, but it is standardized in PNG. So PNG should work well. PNG is a compressed format, and data compression has high overhead (typically 100% to 400%).

There is actually a special mode Chart::QTIMG which outputs BMP for opaque images, and "non-compressed PNG" for translucent images. We use this in our QChartViewer implementation. Being non-compressed, the PNG has much lower overhead, though still higher than BMP. It relies on the fact that Qt can automatically detect the image type, so using either BMP or PNG will work. May be you can try QTIMG to see if it works in your case.

You mentioned the wxWidgets uses "alpha=3" for the chart.

Is it possible the tooltip is rendered in a different way? In our MFC CChartViewer, if there is a CDML tooltip, the tooltip and the chart will first merge onto a buffer (double buffering).

The CDML tooltip is very difficult to implement due to transparency and flickering issues.

It is different for every GUI framework. We tried may be a dozen methods before we found a way that works in MFC.

We found that for MFC, if we implement the tooltip in a separate control floating on top of the chart, it will flicker if both the chart and the tooltip update on mouse move. It is because the drawing sequence will be:

- draw and display the chart
- draw and display the tooltip
- draw and display the chart
- draw and display the tooltip
.........

Some GUI frameworks (like Windows Forms) have the concept of parent/child relationship. If the tooltip control is the child of the chart control, when the chart control displays, it will paint both the chart and its child (the tooltip) to the screen. So the chart does not overwrite the tooltip. However, MFC does not have this concept.

The draw back of the above method is that the tooltip must stay inside the chart. (The default tooltip can partly or fully lie outside the control.) Our tooltip positioning code is designed to ensure the tooltip stays inside the chart.

Some GUI frameworks, such as Qt and WPF, do not have this issue. I guess Qt has internal buffering. Everything drawn in the mouse event, including the chart and the tooltip, will be painted to a memory device context. When our code exits from the mouse event, Qt will copy the memory device to the screen device. By that time, the image contains both the chart and the tooltip, so the tooltip is not overwritten on the screen and there is no flickering.

[...] There is a memory leak and the cursor is not really cached. "QCursor**" should be used instead of "QCursor*" and reference to "cache" within the method should be "*cache". I will need to update the release in the new few days to fix this issue.

I am aware of the "DPI aware per monitor" issue. So far I have not tested exactly what this means for different GUI frameworks. I need to do more tests on how it works.

For MFC, I suspect "DPI aware per monitor" means the DPI of the Window will equal to the DPI of the monitor that displays the Window initially (as opposed to equal to the DPI of the main monitor). Different Windows can have different DPIs. It does not necessarily mean the Window can change DPI when it is dragged from one monitor to the other monitor.

(I can change the monitor DPI by using Settings/Display, but so far I am unable to make an existing MFC Window change DPI. It always stay at the DPI when it is first created.)

I speculate Qt will probably display the cursor at the correct size, even if the DPI changes.
In Qt, our code notifies Qt of the image DPI. If the image DPI does not match the Qt GUI DPI, Qt will automatically resize the image. The drawback is that if Qt needs to resize the image to make it larger, the image will look blurred.

For the remaining occasional flickering, it may be due to the framework painting the control background.

In our code, we override the OnPaint method to paint the background onto a memory buffer, then paint the chart and the tooltip to the buffer, before finally painting the buffer to the display device. This avoids flickering.

Our experience is that GUI frameworks are very different. So it is not surprise the wxWidget framework is different.

In MFC, if the tooltip moves or changes, we only "invalidate" the part of the chart that is affected, not the entire chart. The part that is affected is the "union" of the old and new tooltip box bounding box, which is quite small. So the redrawing should be very fast.

The delay mouse move is to avoid too much mouse move events. Some GUI frameworks can generate lots of mouse events (say 100 per second), and mouse events can jump the message queue. If the mouse move events take too long to process, the system will not have time to process the "OnPaint" event. If our code detects the mouse move events are happening too fast, we will set up a timer and update the chart in the timer event. This combines multiple mouse move events into one timer event.

May be wxWidgets handles painting in the mouse move events different from the timer event, because the mouse move event is an "interactive event".

The delayed mouse event system was designed 15 years ago. By combining mouse events, it makes the GUI more responsive when we need to redraw the a large chart during mouse move, such as for "drag to scroll" or "programmable track cursor" on a full screen chart.

Computers are much faster now, so the delayed mouse event may be less significant. For small updates such as the tooltip, it may have no useful effect at all.