jtransc / gdx-backend-jtransc

GDX backend for JTransc: targeting every platform lime supports (html5, windows, linux, mac, android, ios...) (flash is wip) (consoles + unity likely to be supported in the future)
23 stars 6 forks source link

Files works with big overhed #64

Closed ghost closed 7 years ago

ghost commented 7 years ago

LimeFiles ->

    byte[] bytes = readBytes(pathFixed, mode);
    if (bytes == null) {
     System.out.println("Can't find: " + pathFixed);
     throw new RuntimeException(new FileNotFoundException(path));
    }
    return new JTranscSyncIO.ByteStream(bytes);

first line bytes use readBytes

@HaxeMethodBody("return JA_B.fromBytes(lime.Assets.getBytes(p0._str));")
@JTranscMethodBody(target = "js", value = "return libgdx.io.readBytes(N.istr(p0));")
native private byte[] readBytes(String path, int mode);

go in JA_B.fromBytes

{{ HAXE_METHOD_ANNOTATIONS }}
    static public function fromBytes(bytes:Bytes) {
        if (bytes == null) return null;
        var out = new JA_B(bytes.length);
        var bytesData = bytes.getData();
        for (n in 0 ... bytes.length) out.set(n, Bytes.fastGet(bytesData, n));
        return out;
    }

This is first bytes copy, we can use directly

 {{ HAXE_CONSTRUCTOR_ANNOTATIONS }}
    public function new(length:Int, data: Bytes = null) {

this allocate or directly if already have

Next place in JTranscSyncIO.ByteStream

@Override
  public int read(byte[] data, int offset, int size) {
   int available = (int) (getLength() - getPosition());
   if (available <= 0) return -1;
   int toRead = Math.min(available, size);
   for (int n = 0; n < toRead; n++) {
    data[offset + n] = this.data[this.position + n];
   }
   this.position += toRead;
   return toRead;
  }

Again copy, we have lose memory and time. Can we use blit or memory copy or somethink. We have many big files and when open new window it's create lag.

ghost commented 7 years ago

P.S. Maybe after use #https://github.com/jtransc/jtransc/pull/189 will better, i see it 2 days ago =)

soywiz commented 7 years ago

Even when arraycopy is now optimized, it is always faster to not copy at all. Also less memory required. So i'll check if we can totally avoid duplicating memory.

soywiz commented 7 years ago

This should be fixed by now after the PR is merged ( https://github.com/jtransc/jtransc/pull/189 ). It still requires your approval.

JA_B.fromBytes now just creates a wrapped array + JTranscSyncIO.ByteStream.read now uses optimized System.arraycopy

ghost commented 7 years ago

confirmed fixed.