A couple ideas to improve JavaSE and iOS
I already do it in my app, but I thought of sharing it here as I think that most apps (and CN1 as a platform) would benefit from this
- Implement anti-aliasing in JavaSE images and image operations I currently use https://github.com/mortennobel/java-image-scaling which works great. Images in JavaSE look pretty bad (especially when scaled/rotated), this is kind of a must have Scaling with this library looks like this:
public Object javaScale(Object originalImage, int destWidth, int destHeight){
BufferedImage bufferedImage = (BufferedImage)((com.codename1.ui.Image)originalImage).getImage();
ResampleOp resampleOp = new ResampleOp(destWidth,destHeight);
BufferedImage destImage= resampleOp.filter(bufferedImage, null);
com.codename1.ui.Image cn1Image = com.codename1.ui.Image.createImage(destImage);
return cn1Image;
}
Simply aplying anti-aliasing would call the above method with the image's original dimensions
- Replace Base64 java-based operations with iOS objective-c native operations. Many applications rely heavily on Base64 today. I ran tests on this and using a native objective-c implementation results in 20% increase in performance vs using a java conversion
-(NSString *)encodeBase64:(NSData *)bytesData{
return [bytesData base64Encoding];
}
-(NSData *)decodeBase64:(NSString *)encodedString{
return [[NSData alloc] initWithBase64EncodedString:encodedString options:1];
}
These are just 2 ideas, if they're not cool feel free to close this
The second point sounds interesting and I marked it as an option for future optimization and a good first issue. The first one is a bit problematic with additional dependencies and the question of performance. We already have a higher quality scale algorithm in the designer tool: https://github.com/codenameone/CodenameOne/blob/master/CodenameOneDesigner/src/com/codename1/designer/AddAndScaleMultiImage.java#L287-L329 Probably not as good as that but still better in quality.
The problem is our current API doesn't differentiate between high performance scale and high quality scale. The latter trades off performance and a developer won't necessarily want that even on the desktop. We need a separate API that would generate a high quality scale if available, this shouldn't be too hard. Just add isHighQualityScaleSupported() and scaledHighQuality(int, int) that would default to invoking scaled(int, int). I guess we'd need a similar method for fill.
Is this issue still open? I would like to work on this.
As far as I know, both aren't implemented yet.
@shai-almog so can I work on it? and will you please guide me for it?
@mananmehta3 sure. Which one of the two do you want to focus on?
May I work on this? Can someone help me as I am relatively new to open source contribution?
@shai-almog I would like to work on JavaSE
@pree-T I understand @mananmehta3 is interested in working on this.
@mananmehta3 I don't think this part of the issue should be done in Codename One. This will introduce a 3rd party library dependency that might cause issues and performance regressions. I'm guessing that library can be wrapped in a cn1lib which you can read about here: https://www.codenameone.com/blog/moving-to-maven.html
I am new to open-source contributions and I want to contribute. Can I contribute?
@Ranzeb sure
@Ranzeb sure
Are both these two feature not implemented yet? If yes I will try to implement all of them.
For the second one that is developed on Objective-C, how can I test it? I need to run a MacOs VM in order to develop on Obj-C and try if my solutions works or there are some other options?
@Ranzeb see my comments above. The second one should be applicable. The 1st is a bit problematic. I think the other issue you mentioned might be easier to get started and don't require deep understanding of the code.
Ok
@Ranzeb see my comments above. The second one should be applicable. The 1st is a bit problematic. I think the other issue you mentioned might be easier to get started and don't require deep understanding of the code.
Ok I have read everything.
Now the idea for the second point is to modify directly the objective-C code created by the ParparVM trying to handle the case that you mentioned?