×

Discussion Board

Results 1 to 12 of 12
  1. #1
    Registered User
    Join Date
    Mar 2003
    Posts
    19

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

    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);

    }


    }

  2. #2
    Regular Contributor
    Join Date
    Mar 2003
    Posts
    393
    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

  3. #3
    Registered User
    Join Date
    Mar 2003
    Posts
    17
    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.

  4. #4
    Registered User
    Join Date
    Mar 2003
    Location
    Paris, FRANCE
    Posts
    9
    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
    Last edited by tregnier; 2003-07-09 at 06:56.

  5. #5
    Registered User
    Join Date
    Mar 2003
    Posts
    30
    This is definitely a headache-inducing bug. I'm curious, how did you work around this problem?

  6. #6
    Registered User
    Join Date
    Jul 2003
    Posts
    5
    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.

  7. #7
    Registered User
    Join Date
    Mar 2003
    Location
    Paris, FRANCE
    Posts
    9
    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

  8. #8
    Registered User
    Join Date
    Jul 2003
    Posts
    5
    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...

  9. #9
    Registered User
    Join Date
    Mar 2003
    Location
    Paris, FRANCE
    Posts
    9
    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

  10. #10
    Registered User
    Join Date
    Jul 2003
    Posts
    5
    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.

  11. #11
    Registered User
    Join Date
    Jun 2003
    Posts
    6
    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.

  12. #12
    Registered User
    Join Date
    Nov 2003
    Posts
    7
    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 ...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×