Should Processing 3.0b.1 Be the default download?

shawnlau

I really don't think this beta is ready to be the default download?I tried it out to see if programs perform better, but I know my paint program performs much much worse, unusable worse. It loads without exception ( after removing the tablet functions and library that no longer work with this version). But the draw functions stutter and I even get a a twirling circle. I don't know what the problem is, but I don't think this should be the default download version. Pretty IDE's don't make a useful program.

2.2.1 should still be the default download.

shawnlau

To explain further, I am working on unique paint program where you paint on several layers (separate colors, and probably optional separate brush sizes) at one time, probably up to 4. Now that's a lot of work for each mouse drag, but so far, Processing 2 gets the job done without stuttering. I'm using PGraphics for the layers. The program also has a function where you can separate high frequency details form low frequency details using a bidirectional median filter separating the two. I'm pretty pleased with the way its turning out except for the limitations of stroke(). I need a way to fix that at low levels because at lat very low alpha ( e.g., stroke (245, 200, 100, 4) ) it posterizes color in the blend mode, and I think it because it uses a linear blending mode. I have to find a way to fix that and thats the main reason I tried the beta - to see if it was fixed. The beta isn't working for me at all. Everything stutters.

Its a lot of code and I'm still working on the separate frequencies mode, but I will post the code on gist.githup within a couple of days.

Here's a link to the beginning version. Its progressed much since then. https://gist.github.com/shawnlau/57b98a4d10110a74a6ea

shawnlau

New code here:

https://gist.github.com/shawnlau/cc3eae823fe652f486b8

PhiLho

I don't see any "default download", just a list of versions. The beta version is, by definition, unstable, it is here to be tested and problems reported to the GitHub issues.

shawnlau

Go to cover download and see what version is on the download page. I also get a nag screen every few days that a newer version is available. 3.0 beta 3 is the default download.

PhiLho

What do you call "default download"? I see four versions to download, including the latest betas (which shouldn't be listed as "stable", though).

shawnlau

When I go to cover and press the download link I go to a page that asks if you want to donate, then to the download page. 3.0 beta 3 is the program next to the big "P" logo. Also in some of the new documentation, it states Processing 3 is the default download. And if you have "check for updates" checked in preferences, you will receive a notification that a new version is available.

shawnlau

And the beta might be excellent. It just isn't working for me right now and it could certainly be that I don't have it set up correctly. 2.2.1 works much better for me.

GoToLoop

Best version is 3.0a5. Which is the last 1 to still depend on Applet.
But they removed that option. Arf! [-(

shawnlau

I don't know enough about it, but in my case, the beta stuttered so much it was unusable for my program. Its likely I have it set up wrong, but right now I'm so excited about the opportunity to develop a program I've been thinking about for years, I'm not inclined to lose my train of thought on trouble shooting a beta. 2.2.1 is working great for my case.

Chrisir

you could file a bug report for those bugs

Bird

@shawnlau I'm in the same boat. I'd stick to 2.2.1 until you are ready to migrate to 3, if ever. I am also working on a painting program in which I can drag, rotate and scale the layers on multiple pages and output it as a pdf book. I cobbled (stole) together a smudge function that I think you might like. I had to modify it to make it work with processing and it works fairly well with alpha in the image, but it does darken the lighter pixels in proximity to alpha. I also constrained the smudge area to a range from 4 to 12 pixels. Rather than drawing a line with mouseDragged(), you use the function to smudge a region of pixels along a line. The function requires a few global variables, but is otherwise self-contained. I think you could add it to your code easily, if you wish. Smudging is a necessity for me.

double[][] smudgeRed, smudgeGreen, smudgeBlue, smudgeTrans; 

// inside setup:

 smudgeRed = new double[10][10];
  smudgeGreen = new double[10][10];
  smudgeBlue = new double[10][10];
  smudgeTrans = new double[10][10];

// end setup


void applySmudgeAlongLine(PGraphics _image, int x1, int y1, int x2, int y2, float _scale) {
  int w = _image.width;
  int h = _image.height;
  _image.loadPixels();
  int smudgeRadius = constrain (int (7/_scale), 4, 12);
  final int cp[] = _image.pixels;
  for (int i = 0; i < smudgeRadius; i++)
    for (int j = 0; j < smudgeRadius; j++) {
      int r = y1 + j - int(smudgeRadius/2);
      int c = x1 + i - int(smudgeRadius/2);
      if (r < 0 || r >= h || c < 0 || c >= w) {
        smudgeRed[i][j] = -1;
      } else {
        int getColor = cp[c+r*w];
        smudgeTrans[i][j] = (getColor >> 24) & 0xFF;
        smudgeRed[i][j] = (getColor >> 16) & 0xFF;
        smudgeGreen[i][j] = (getColor >> 8) & 0xFF;
        smudgeBlue[i][j] = getColor & 0xFF;
      }
    }
  int dist = Math.max(Math.abs(x2-x1), Math.abs(y2-y1));
  double dx = (double)(x2-x1)/dist;
  double dy = (double)(y2-y1)/dist;
  for (int d = 1; d <= dist; d++) {
    int x = (int)Math.round(x1 + dx*d);
    int y = (int)Math.round(y1 + dy*d);
    for (int i = 0; i < smudgeRadius; i++)
      for (int j = 0; j < smudgeRadius; j++) {
        int r = y + j - int(smudgeRadius/2);
        int c = x + i - int(smudgeRadius/2);
        if (!(r < 0 || r >= h || c < 0 || c >= w || smudgeRed[i][j] == -1)) {
          int curCol = cp[c+r*w];
          int curTrans = (curCol >> 24) & 0xFF;
          int curRed = (curCol >> 16) & 0xFF;
          int curGreen = (curCol >> 8) & 0xFF;
          int curBlue = curCol & 0xFF;
          int newTrans = (int)(curTrans*0.7 + smudgeTrans[i][j]*0.3);
          int newRed = (int)(curRed*(0.7) + smudgeRed[i][j]*(1.0-(0.7)));
          int newGreen = (int)(curGreen*(0.7) + smudgeGreen[i][j]*(1.0-(0.7)));
          int newBlue = (int)(curBlue*(0.7) + smudgeBlue[i][j]*(1.0-(0.7)));
          int newCol = newTrans << 24 | newRed << 16 | newGreen << 8 | newBlue;
          cp[c+r*w] = newCol;
        } else {
          println("Not");
        }
      }
  }
  _image.updatePixels();
}

shawnlau

Thanks so much. I'm certainly going to go through it! Copied and saved. I could us smudge also. I've posted some code on Github, but its changing so much so fast, it looks very different. I have a GUI now and an alternate view window where you can look at your work flipped one way and work on it the other way. You can zoom and flip, and alter the brightness contrast of each window individually.

Big problems I have left to solve are a better way to mix color and getting a smooth stroke. Linear mixing is giving too many errant hues, and I have to create a smoother stroke function. I think I can modify a blur routine I found to paint a smooth stroke.

shawnlau

I posted the modified blur routine. It works pretty well but I think I can get it to work better. Its toward the end of the thread I'm linking:

http://forum.processing.org/two/discussion/12048/why-do-i-have-to-call-pg-begindraw-pg-enddraw-0-on-a-pgraphics-i-m-copying-not-drawing-on#latest

Bird

Very cool. I plugged the smudge function into the code you gave earlier and got it to work. Needed to create a Boolean that toggled on and off with a keystroke. I have yet to incorporate brightness and contrast. I also "borrowed" some code from @Chrisir for a fill function, which was very handy.

Bird

Very nice blur routine. I like the quality of the line. Well done.

shawnlau

Here is the brightness/contrast routine in draw(). It stutters some and its the clipping check that causes it to be slow. If I could think of a better way to do that. I use it mostly in the alternate view window because that has its own draw() function and the main window still draws() fine. The dX and zX etc are offsets from when the window is dragged or zoomed.

void draw() {
     background(100);

     if(enhanced){
          layers[curLayer].beginDraw();
          imgEnhanced.beginDraw();
          layers[curLayer].loadPixels();
          imgEnhanced.loadPixels();
          int r,g,b;
          color inColor;
          for(int i = 0; i< numberOfPixels; i++){
               inColor = layers[curLayer].pixels[i];
               r = (inColor >>16) & 0xFF;
               g = (inColor >>8) & 0xFF;
               b = inColor & 0xFF;
               r = (int)(r * eContrast + eBrightness);
               g = (int)(g * eContrast + eBrightness);
               b = (int)(b * eContrast + eBrightness);
               r = r < 0 ? 0 : r > 255 ? 255 : r;
               g = g < 0 ? 0 : g > 255 ? 255 : g;
               b = b < 0 ? 0 : b > 255 ? 255 : b;

               imgEnhanced.pixels[i] = 0xff000000 | (r << 16) | (g << 8) | b;
          }
          imgEnhanced.updatePixels();
          layers[curLayer].endDraw();
          imgEnhanced.endDraw();
          cX = dX+zX;
          cY= dY+zY;         
          image(imgEnhanced, cX, cY, img.width * zoom, img.height * zoom);
     }