A bug: setColor with offscreen graphics - PLEASE, REPLY THIS TIME

[palmcrust]

The following message was sent quite a while ago. and still no answer.

I am extremely interested to find out, if a bug repeats somewhere else (especially with Series 40 and Series 30 models).

The bug was so crucial for our application that we had to redesign the whole drawing logic with obvious lattency increase. For a Series 30 patching the bug would be simply impossible because of getting out of allowed midlet size.

As a matter of fact, setColour is ignored not only for drawing text, but for drawing lines as well.

I wish the bug to be recorded by Nokia personnel for further fix. I would also like to know is there will be a way to reflash (free of charge) Nokia 3650 ROM after the bug is fixed (BTW, are there any tools for reflashing Nokia ROM ?)

Sorry for being rude - this is really an awful bug.

Regards
Michael


---------------------------------

A BUG!!! Drawing to image graphics (3650)

The following (ready to use code) illustrates an awful bug noticed when running my 3650 device (all Nokia emulators I tried, work OK):

If you draw a text (width drawString) to an image graphics (obtained with getGraphics from an Image), the setColor command is ignored: all text is drawn in default black colour (can you guess what you will see on a black background ?).

If you noticed same problem on another (S60, S40 or S30) device, please answer this message.

Lookig forward...
Michael

---------------------------------------------
***********************************
TestGraphics.jad
-------------------------------------------------

MIDlet-1: TestGraphics, TestGraphics.png, com.palmcrust.testgraphics.TestGraphics
MIDlet-Jar-Size: 2460
MIDlet-Jar-URL: TestGraphics.jar
MIDlet-Name: Test Graphics
MIDlet-Vendor: Sun Microsystems
MIDlet-Version: 1.0

***********************************
TestGraphics.java
-------------------------------------------------
package com.palmcrust.testgraphics;

import javax.microedition.midlet.MIDlet;
import javax.microedition.lcdui.*;


public class TestGraphics extends MIDlet
{
TestCanvas tstCanvas;

// 'true' disables using image Graphics
static final boolean drawDirectly = false;

public TestGraphics() {
tstCanvas = null;
}

public void startApp() {
tstCanvas = new TestCanvas(this);
Display.getDisplay(this).setCurrent(tstCanvas);
}

public void pauseApp() {}
public void destroyApp(boolean unc) {}
}

class TestCanvas extends Canvas
{
private TestGraphics midlet;
Graphics testImgGraphics;
Image testImage;
Font textFont, smallFont;
int w, h, fh, fhs;

private static final String sampleString="Hello, world !";
private static final String drawTypeStringDirect="Directly to canvas";
private static final String drawTypeStringIndirect="Using image graphics";
private String drawTypeString;

TestCanvas(TestGraphics _midlet)
{
midlet = _midlet;
testImage = null;
testImgGraphics = null;

w = getWidth();
h = getHeight();

// Lookig for bold italic font
textFont = Font.getFont(Font.FACE_PROPORTIONAL,
Font.STYLE_BOLD,
Font.SIZE_MEDIUM);
fh = textFont.getHeight();
smallFont = Font.getFont(Font.FACE_PROPORTIONAL,
Font.STYLE_ITALIC,
Font.SIZE_MEDIUM);
fhs = smallFont.getHeight();


if (!midlet.drawDirectly) {
testImage = Image.createImage(w, h);
testImgGraphics = testImage.getGraphics();
drawTypeString = drawTypeStringIndirect;
} else
drawTypeString = drawTypeStringDirect;
}

public void paint(Graphics g)
{
if (testImgGraphics == null)
drawSampleTextBoldItalicYellow(g);
else {
drawSampleTextBoldItalicYellow(testImgGraphics);
g.drawImage(testImage, 0, 0, Graphics.TOP | Graphics.LEFT);
}

}

private void drawSampleTextBoldItalicYellow(Graphics g)
{

g.setColor(0, 0, 128);
g.fillRect(0, 0, w, h);

g.setColor(255, 255, 0);
g.setFont(textFont);
g.drawString(sampleString, w >>> 1, (h-fh) >>> 1,
Graphics.HCENTER | Graphics.TOP);

g.setFont(smallFont);
g.setColor(0, 255, 255);
g.drawString(drawTypeString, w >>> 1, h-fhs,
Graphics.HCENTER | Graphics.TOP);

}


}

[nmittal]

As the devices are already double buffered, please dont use double buffering as that leads to the issue that you are mentioning. If you draw the string directly to the canvas it will be drawn in the correct colour. It is always a good idea to check for double buffering by using isDoubleBuffered and then deciding whether to use double buffering or not. This will keep the application portable.

[N]/Forum Nokia

[Dess]

Hi nmittal,

Yes but it's pretty annoying for ppl who wants to code for example a demo with a "sin scrolltext" w/ the current fonts. The only solution is to create our own fonts, super. Thanks nokia.

[tregnier]

Hi,

The answer from Nokia is not appropriate.

It is correct only if you manage the paint of the screen yourself, that is if you use a Canvas.

But, drawing text in images is very useful (and simple) to have nice Forms.
Forms have no centering, or right justified text.
Draw a (small) text in an image, and voila! you can display it centered or on the right side of the screen.

So Nokia response is (perhaps) appropriate for games, but for business application, they offer no solution (yet).

I'm displaying travel schedules. It's full text, several screens long. In order to enlight the times of departure of each part of a journey, I display them right justified in reverse video (I could also display them bold, or italic for instance).

I don't want to use a Canvas, because I should redo all the work made by the Form class. Furthermore, users wouldn't have a consistent look and feel on their phone.
For instance on series 60, there are small arrows at the bottom of the screen to show that you can scroll, on series 40 it is a slider on the right side of the screen, and I don't even speak of non Nokia phones. How could I do draw the right widgets simply myself ?

I'm not asking for a new feature, just for a bug correction. The setColor method is very useful as you can see.

So please, Nokia, this setColor bug, is more important than what you explain. It's so sad to see that only the best phones (series 60) have a poor display, whereas they are supposed to be the more approriate for business applications.

Thank you.

Thibaut REGNIER

[wesbiggs]

This is definitely a headache-inducing bug. I'm curious, how did you work around this problem?

[Dess2]

You can't really bypass the problem. Either you draw all strings immediately to the only Graphics given by the paint method, OR use your own bitmap fonts (which u have to colour yourself).
And imho, it's useless to wait for a fix from nokia because even if it's fixed in a new firmware, you're sure some ppl still have older firmwares. It's a big problem if you expect to release your work to the public, commercial or free that's it.

[tregnier]

And if you add images to a Form there is no paint method, so there is no solution.

I'm not as pessimistic as Dess2, if Nokia would correct this bug.
If it is corrected rapidly, only a few proportion of the phones would have the problem, and you have to find a workaround for your midlet only if it's a major issue (like text on a black background). Else if it's just (very) difficult to read, you could propose your users who have those buggy phones to go to a Nokia shop to upgrade their firmware (I suppose that a new firmware would be released).

But what is really important is that Nokia correct the bug quickly in a new firmware. I hope they don't see it as a "feature" of serie 60 phones. As more and more midlets come to the market, the bug will be reported more and more frequently.
My midlet is not designed for series 60 phones, it is designed for all the Java phones, from all vendors. One display was strange, and I've reported this bug.

Now if someone with glasses ask me which powerful phone to buy, I would recommend to buy Motorola or Sony, because black text on dark colored background needs very good eyes ;-)

Please Nokia, do you read this forum ? Let us now what you plan for this bug.

Thibaut REGNIER

[Dess2]

Sorry, i won't debate long about the subject but I'm not pessimistic, i'm just realistic. Let's see what will happen with your last question...

[tregnier]

Unfortunately, Dess2 seems to be right.

Is there someone from Nokia reading this forum ?
If so could they give their plan about this BUG which occurs only on series 60 platform (7650, 3650, and the future N-Gage).

If we have no answer, I will create a known bug page on the website of the French Java User Group, one of the top 25 JUG in the world.
Developper should have access to a list of known bugs without fix from the phone makers.

Stay tuned

Thanks.

Thibaut REGNIER
http://www.club-java.com

[Dess2]

Hi Thibaut,

Listing all known bugs would help a lot, especially with the solutions to avoid/fix them. I would be glad to participate to this action,

Best regards,
D.

[Lores]

The use of offscreen surfaces is not limited to double buffering - i've used it because of speed issues.
Every other Device except Series60 handles these Offscreen Surfaces correctly.
The implementation has bugs, face it and don't deny it.

[vahur12]

The bug is present is Symbian 6.1 emulator too, so most likely it will be in other phones too which use this version of Symbian. I have Siemens SX1 emulator and the bug is there too ...