Graphics.Clear() not working for canvas?

[Kadith]

Hey everyone,

I couldn't see anyone else having this issue in the forums so it might be something I'm doing but it seems that if Phaser is using a canvas element the graphics.clear function doesn't seem to work. Setting it to WebGL however does.

Here's a small bit of code that replicates the issue:

var config = {
    type: Phaser.CANVAS, //Change to WEBGL and clear works.
    parent: 'phaser-example',
    width: 800,
    height: 600,
    scene: {
        preload: preload,
        create: create,
        update: update
    }
};

var game = new Phaser.Game(config);
var graphics = null;

function preload ()
{
}

function create ()
{
    this.input.on('pointermove', onMove);
    graphics = this.make.graphics({x: 0, y: 0, add: true});
}

function onMove(pointer)
{
    graphics.clear();
    graphics.lineStyle(1, 0x167EFE, 1);
    graphics.moveTo(0,0);
    graphics.lineTo(pointer.worldX, pointer.worldY);
    graphics.moveTo(800,0);
    graphics.lineTo(pointer.worldX, pointer.worldY);
    graphics.moveTo(800,600);
    graphics.lineTo(pointer.worldX, pointer.worldY);
    graphics.moveTo(0,600);
    graphics.lineTo(pointer.worldX, pointer.worldY);
    graphics.strokePath();
}

I used http://labs.phaser.io/edit.html to run it under Linux using both Chromium and Firefox, had the same issue on both browsers as well as Samsung Galaxy Tab A (in Chrome, Firefox and the default Samsung internet browser).

Has anyone else seen this?

Thanks,

Kadith.

[rich]

Ironically, Canvas is doing it correctly, it's WebGL that should be leaving the trail all over the screen, because there's no call to 'beginPath' before the first 'moveTo', so the path is getting exponentially longer each time you move the pointer.

Although I do think there's a good argument for 'clear' to automatically insert a 'beginPath' into the command stack for you.

[Kadith]

9 minutes ago, rich said:

Ironically, Canvas is doing it correctly, it's WebGL that should be leaving the trail all over the screen, because there's no call to 'beginPath' before the first 'moveTo', so the path is getting exponentially longer each time you move the pointer.

Although I do think there's a good argument for 'clear' to automatically insert a 'beginPath' into the command stack for you.

At least it's something minor that I missed rather than a big issue! Thanks for the reply!!

Think I had the assumption that I only needed to use beginPath if I wanted to fill a shape with a colour. I'll have to go through and update my code!

Thanks again for the help!

 

[rich]

I updated the master branch last night so it now automatically starts all Graphics renders with a beginPath. It’s a bit frustrating (the way canvas works) because you’d hope that saving and restoring the context would do the same for paths, but it doesn’t.

You should use beginPath at any point in a Graphics object when you wish to signify the end of a section of the drawing. Basically, use it a lot ?

[Kadith]

I'll try and grab a copy and give it a go later today.

And yeah, it would make sense that saving and restoring the context would include the path, unless for some reason they don't store the path as part of the context...which would be weird.

Will keep that in mind for the future, thanks again for the help as well!

[Kadith]

I forgot to mention the other day that looks like it works in my case as well, although I've now changed my code to properly use beginPath in all the draw cases I need.