drawTextPixel() is too slow

[clearpicks]

Due to the bug in Text.RELATIVETOLEFT bug, as a workaround, I used drawTextPixel() to replace drawTextAbsolute() to display some information in realtime. However I just found out drawTextPixel() updates the text shown much slower than drawTextAbsolute(). Attached is a testing script. Apply it on YM, M8 chart to see the difference between these two functions. The one drawn by drawTextPixel() updates at very lower frequency. Also it seems mouse clicking on the chart may force the text drawn by drawTextPixel() to get refreshed. Please fix this bug!!!!!!!!!!!!!!!!!!!!!!!!!!!


- Clearpicks

[ACM]

Re: drawTextPixel() is too slow

clearpicks
At my end the difference between the two functions is hardly noticeable. If anything text drawn with drawTextPixel() seems to be somewhat more responsive as I can see some changes in prices that barely register with drawTextAbsolute(). I tested it also on ES #F that tends to have a higher trade rate than YM #F and using both version 8 and version 10 build 1086.
Anyhow I believe Jason has already indicated that the issue of drawTextAbsolute() had been passed to the developers
Alex

Originally posted by clearpicks
Due to the bug in Text.RELATIVETOLEFT bug, as a workaround, I used drawTextPixel() to replace drawTextAbsolute() to display some information in realtime. However I just found out drawTextPixel() updates the text shown much slower than drawTextAbsolute(). Attached is a testing script. Apply it on YM, M8 chart to see the difference between these two functions. The one drawn by drawTextPixel() updates at very lower frequency. Also it seems mouse clicking on the chart may force the text drawn by drawTextPixel() to get refreshed. Please fix this bug!!!!!!!!!!!!!!!!!!!!!!!!!!!


- Clearpicks

[clearpicks]

Re: Re: drawTextPixel() is too slow

Right now it seems working fine. I observed the problem during and after the high volume period this morning.
Because right now the market is lightly traded, it is of no surprise that it works fine. I also restarted eSignal about one hour ago.
My testing was done between 10:45 -- 10:55.

eSignal always works fine in lightly traded hour, while in busy trading hour, which is the most critical time period for the users, it just has various problems. A software should not only work smoothly in light-loaded condition.

Regarding to the reason of slow update of the texts drawn by drawTextPixel() during/after busy period, I suspect that the area on the chart is not updated ( redrawn/repainted promtly ) promtly by the charting engine, however the charting engined is forced to update (redraw/paint) the area where the text drawn by drawTextAbsolute() is located.

One thing might be helpful to trace such bug is that it seems clicking mouse on the chart forces the charting engine to repaint the text drawn by drawTextPixel().

- Clearpicks

[clearpicks]

This script also drawn the second along with the price.

To reproduce the problem, wait for the next busy trading hour prefered something like this morning and open at least a few charts with not so simple EFS' attached. When I was writing the testing script, YM M8 was updating at the rate above 10 times per second. However I think such rate is not important. The true triger causing the problem was the busy trading hour arround 10 o'clock, which might corrupted something (variables) within the charting engine.

- Clearpicks

[clearpicks]

It happened again. I upload a screenshot. However it can not show the prboem I observed because whenever I click on the chart or drag the screencapture icon to the chart, the texts are refreshed so that they seem correct. Anyway, what I saw was that both texts on chart were not updated promptly. However the price part in the right text was updated and always showed the correct last price. I think it was because the last digit overlaps with the last bar on chart so that somethow it was forced to repaint.

I reported a bug regarding flashing text in http://forum.esignalcentral.com/show...threadid=25799

I believe it is this bug happenly hiding the lagging issue of drawTextAbsolute() in my test example. So I modified my testing script and added one more test (Fast40) at Bar -40. Because it does not ovelap with the last bar, it lags also same as the drawTextPixel().

So in summary, drawTextXXX() APIs do not repaint promptly in some heavy trading period while if the text overlaps with the last bar, it is updated very fast and without no problem to catch even the fast moving market. So this is not a CPU or graphics card issue. It is simply an eSignal implementation issue.

[clearpicks]

Please confirm there is a lagging in repaint bug in drawTextXXXXXX() functions so that it may be fixed in the future release. Thanks

Hi clearpicks,

You should be able to press the 'Print Scrn' button on your keyboard to capture a screen shot without the refresh issue you are discussing. Then paste the screenshot into an open file, save it and upload the file to display the screenshot on the forum.

Originally posted by clearpicks
It happened again. I upload a screenshot. However it can not show the prboem I observed because whenever I click on the chart or drag the screencapture icon to the chart, the texts are refreshed so that they seem correct. Anyway, what I saw was that both texts on chart were not updated promptly. However the price part in the right text was updated and always showed the correct last price. I think it was because the last digit overlaps with the last bar on chart so that somethow it was forced to repaint.

[clearpicks]

I made some modification to the testing script so that it shows the same sequence number for all three texts drawn on the screen. In the screen capture uploaded, you may see that the price drawn at bar 0 is different from the other two although they have the same sequence numbers. This is because the price part of the third text is forced to be repainted while candlestick bar 0 is updating while the other two are not repaint so frequently. Maybe such laziness in repainting text was introduced by eSignal development team to save a little bit CPU usage, however this kind of implementation is not correct. For example, if we try to use drawTextXXX to display the latest price quote, then in fast moving market, it would simply show the incorrect prices.

BTW, testing it on YM is more easy to reproduce the bug because although ES has more volume than YM, but YM has more price changes per second.

[clearpicks]

The screen capture.

Fast: 102 12240
Fast40: 102 12244
Slow: 102 12244

[clearpicks]

Another screenshot. The right text was being updated very fast, however somehow the left two were not updated fast enough. It is an obvious bug in eSignal EFS.

[clearpicks]

Anyone to confirm this is a bug and will be fixed in the future release?

[eSignal_JasonK]

Hello Clearpicks,

So far I'm not able to confirm this as a bug, but I will continue to investigate.

[clearpicks]

Jason,

Thank you for your effort. You'd better check the source code to find out how and when the program updates ( refreshes ) the area where the text is located. It seems esignal updates the rectangle area of the last several bars much frequently than the other area on the same chart, because I could see the text on the right was updated very very fast. So this is definitely not a graphics card or CPU usage issue. But opening more charts and load many efs to inflate the cpu usage to at least 50% may help you reproduce the issue more easily. This seems also closely related the flashing bug which still exists in the latest esignal v10 version released. Hope these clues help.

- Clearpicks

Originally posted by JasonK
Hello Clearpicks,

So far I'm not able to confirm this as a bug, but I will continue to investigate.

[eSignal_JasonK]

Hello Clearpicks,

Here's some more information for you. This behaviour is not specific to EFS functionality or the drawTextPixel() function. You can place text labels to overlap the current bar drawn by any of the text functions and you will see the same behaviour. What is happening is that the graphics of the chart on the first 3 bars are updated faster that the rest of the chart area. I believe this is intentional design. Changing the refresh rate to force the entire chart to update graphically at the same rate as the first 3 bars would more than likely increase CPU requirements. I don't think this is something that should be changed.

The text flashing bug has not yet been addressed. It is a known issue and we will fix it.

[clearpicks]

Hi Jason,


Thank you for your response. The explanation you gave is same as what I thought. I have no idea how eSignal charting engine is implemented, thus I am not sure whether it is possible to only immediately update the text area right after drawTextXXX() is called. If the answer is yet, how much performance gain does this intensionally limited text update rate achieved in the cost of text not being updated in realtime? From my observation and experience, such gain might be very little. If the whole area except the first 3 bars all needs to be updated, then you might be right, and the current design is a correct tradeoff decision.


- Clearpicks