Images aren't colored correctly

[Andrew-J-Larson]

For example using anything like pixel art, there is usually one major used color that just blanks out to white for some weird reason... since I was thinking maybe it was a color palette problem, I made a completely color compatible pixel art image to have the extension to draw, and it still blanked out one of the colors to white for some reason... I was able to somehow fix the issue with some images by adding a big white border. For others, actually adding a palette of the compatible colors (with reasonable size) in one of the corners (after white border is created) would help... But both aren't reliable methods, because I still found tons of images not working trying to use those short lived tricks.

As you can tell in this example image, the palette is a perfect match with the colors you can draw with in game. Now, let's take a look at the result on skribbl.

As you can see, it pretty much drew it, but with an exception... it never drew a single bit of the lighter gray. This is the bug I'm talking about.

As for trying this on other images, it won't always be the same color, but it usually happens to either the first or second most abundant color in the image (excluding white), at least from what I could see.

Hopefully this helps a bit

[Andrew-J-Larson]

I'm assuming that maybe an image with the second majority color being white, is what allows some images to appear fine, in the cases where I didn't get this missing color issue.

[galehouse5]

Thank you for the detailed investigation, @TheAlienDrew. I am having some trouble reproducing the issue on my end using the provided image.

There's an optimization that helps draw an image faster by reducing the number of lines we need to draw. It finds the most common color (in terms of line count) and uses the fill tool (or paint bucket) to draw that color everywhere so it doesn't need to use lines. That way it can draw the most common color in a single fill operation, sparing many line drawing operations.

The problem looks to be that the fill color is never drawn so it might have something to do with clicking the fill tool on the canvas. You could play with the canvas coordinates we use for the fill tool click to see if that does anything:

artist.js:28

const fillCanvas = function (color) {
    return [
        function () {
            toolbar.setFillTool();
            toolbar.setColor(color);
            canvas.draw([
                { x: 0, y: 0 },
                { x: 0, y: 0 }
            ]);
        }
    ];
};

You might want to try reproducing in an incognito window to rule out interference by third-party extensions. You could also try on a different OS or computer if you have one available. Things are working for me right now on Chrome 80.0.3987.106 and Windows 10 Pro 1909 but I'm happy to fix this if you can help me reproduce it.

[Andrew-J-Larson]

Could it be possible that uBlock Origin and/or Privacy Badger could be the problem? Those are the only extensions that I allow in incognito (which I also tested when I used the autodraw)

On Sun, Feb 16, 2020, 12:30 PM Mitch Galehouse notifications@github.com wrote:

Thank you for the detailed investigation, @TheAlienDrew https://github.com/TheAlienDrew. I am having some trouble reproducing the issue on my end using the provided image.

[image: image] https://user-images.githubusercontent.com/1687988/74611371-340ae800-50c9-11ea-86ad-5498b577fa2f.png

There's an optimization that helps draw an image faster by reducing the number of lines we need to draw. It finds the most common color (in terms of line count) and uses the fill tool (or paint bucket) to draw that color everywhere so it doesn't need to use lines. That way it can draw the most common color in a single fill operation, sparing many line drawing operations.

The problem looks to be that the fill color is never drawn so it might have something to do with clicking the fill tool on the canvas. You could play with the canvas coordinates we use for the fill tool click to see if that does anything:

artist.js:28

const fillCanvas = function (color) { return [ function () { toolbar.setFillTool(); toolbar.setColor(color); canvas.draw([ { x: 0, y: 0 }, { x: 0, y: 0 } ]); } ]; };

You might want to try reproducing in an incognito window to rule out interference by third-party extensions. You could also try on a different OS or computer if you have one available. Things are working for me right now on Chrome 80.0.3987.106 and Windows 10 Pro 1909 but I'm happy to fix this if you can help me reproduce it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/galehouse5/skribbl-io-autodraw/issues/12?email_source=notifications&email_token=AEV3C5A2QMYYNMRDYD7F273RDGO5VA5CNFSM4KURTPG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL4RKXQ#issuecomment-586749278, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEV3C5G454WUK5IODR7TZODRDGO5VANCNFSM4KURTPGQ .

[Andrew-J-Larson]

Well... I just tried it with all extensions disabled except for yours, and it's still doing the same thing, not getting the predominant color... Are you sure there isn't something different about the Chrome Web Store's version from the one you are using? @galehouse5

[Andrew-J-Larson]

Did another test, but with a Chromium based browser... interestingly enough... it works, with quirks.

When using Chromium Edge with the extension, the first time, it didn't show the background in it, but it did show it on Chrome... further tests didn't draw the background on either view though.

When using Chrome with the extension, no matter what, background wasn't drawn on either browser.

I'm thinking that maybe it's a speed race issue with the server when the background is filled in... (e.g. have the fill action click for longer... or more than once to get the background fill)

[Andrew-J-Larson]

It's definitely timing! I figured it out with the code....

I'll be forking and sending my changes your way soon.

[galehouse5]

Thanks @TheAlienDrew! Good work.

[Andrew-J-Larson]

Never mind, my code was a fluke... but I can be certain about something,,, I think that on slower networks... the script is too fast at identifying the toolbar, or running the first few commands in the array.

[Andrew-J-Larson]

Like, I tried to log anything when it came to the setting the background, and nothing would even show in debug... making me think that something is not waiting for the website to load before the script tries to search through the page.

[Andrew-J-Larson]

Okay, truly figured out the issue now!

@galehouse5 from what I can tell... sometimes the first command in the array won't execute on some computers/browsers/networks... anyways, to counter this I just added a dummy log command as the first command to execute so that way the background fill command goes through.

Will be sending changes soon.

[Andrew-J-Larson]

@galehouse5 I sent the merge, go ahead and review it... I edited the minified version too if that was needed, otherwise, in the source files you should see what the actual change is.

I made sure it was working, after I loaded the unpacked extension into my browser and tested it, and the background shows up fine now... did 4 tests all exceeding.

[galehouse5]

Thanks for your help @TheAlienDrew!

I did some investigation into the timing issue and discovered the source of the problem. When clearing the canvas, Skribbl actually clears the canvas twice. The second clear gets echoed back from the server so is affected by network latency and we have to wait for it before we start drawing.

I implemented a slightly different solution in 89edc91 that waits for the second clear. Would you mind testing that it fixes the problem?

[Andrew-J-Larson]

@galehouse5 Yep, that fixed it!

[Andrew-J-Larson]

Also, it feels a little bit faster too, whatever else you changed, so thanks 👍

[galehouse5]

Glad to hear! This change is merged to master now. I updated the package in Chrome Web Store but it's pending manual review.