I'm new to cesium, when i use this software, i always get warning in Chrome's console: Canvas2D: Multiple readback operations using getImageData are faster with the willReadFrequently attribute set to true. See:
I guess there could be some setting to switch it on, but don't know how.
Anybody can help, thanks!
Thanks & Regards,
Martin.
I'm also facing the same issue and found the solution given below on Stack Overflow:
const ctx = canvas.getContext('2d', {willReadFrequently: true});
But it needs to change directly into cesium.js which is not possible from the developers end.
Related
I'm trying to get chrome's V8 (d8) x64.release version to use the V8 support tools in GDB, specifically for the job and telescope commands (predominantly the former).
My x64.debug version has this implemented and works, but even after building the x64.release version in a similar manner I still cannot get these commands to work in the x64.release version. The output is always as:
gef⤠job 0xd98082f7b51
No symbol "_v8_internal_Print_Object" in current context.
I have set args.gn before, and after building via ninja -C to include v8_enable_object_print = true in my args.gn:
is_debug = false
target_cpu = "x64"
use_goma = false
v8_enable_object_print = true
v8_enable_disassembler = true
I also have my ~/.gdbinit containing:
source ~/Desktop/tools/v8/tools/gdbinit
source ~/Desktop/tools/v8/tools/gdb-v8-support.py
See: https://chromium.googlesource.com/v8/v8/+/refs/heads/main/tools/gdbinit (for the support tool I'm trying to build V8 with).
How can I get my /v8/out.gn/x64.release/d8 to run with compatibility of the job command?
Am I missing something here? If so your help would be very helpful.
EDIT Alternatively how can I disable all x64.debug V8 DCHECKS?
Thanks all, appreciate your time here.
How can I get my /v8/out.gn/x64.release/d8 to run with compatibility of the job command?
I'm not sure. Try adding symbol_level = 1 (or even symbol_level = 2) to your args.gn. That definitely helps with stack traces, and might also be the thing that lets GDB find the _v8_internal_Print_Object function by name.
Alternatively how can I disable all x64.debug V8 DCHECKS?
There is no flag to disable them, but you can edit the source to make them do nothing. See src/base/logging.h.
I need to activate the profile setting forceDoubleSided in order to display properly a model derivated from a Revit project that has mirrored external references.
Using the latest version of the Forge Viewer, I set the profile settings in the config parameter when I call new GuiViewer3D(container, config) and, while the model is loading, the materials property "side" = 2 (THREE.DoubleSide) and it looks good.
The problem is when the model has loaded, or after have used the cutting plane extension, because the materials "side" is then reset to 0 (THREE.FrontSide) so the model stops looking correctly.
As a workaround, in the GEOMETRY_LOADED_EVENT and CUTPLANES_CHANGE_EVENT events I am executing _viewer.impl.setDoubleSided(true, _viewer.model) every time.
It seems like a bug in the viewer... is there a better approach to handle this problem?
That does sound like a bug. Let me notify the engineering team, and thanks for reporting it! For now, please continue manually overriding the "sidedness" as needed.
I'm upgrading from an old version of PDF.JS (1.9.426) to the latest stable (2.5.207).
Previously, it was very simple to force the locale to match your applications current locale.
You simply pass it through as a parameter in the URL;
/PDFJS/web/viewer.html?file=example.pdf #locale=zh-CN
However, on upgrading, I see that this is no longer recommended.
This is despite the documentation still mentioning it.
In my application, users can override their prefered locale, so it might not match the browser.
I've looked into embed / object, which seemed like the solution, until I realised Android browsers don't support embedded PDF viewing.
I've been searching for the correct way to implement this, and so far I've not found a good or recommended answer.
It seems PDF.js is still the best all round solution, but I can't figure out the correct way of using it to simply render an existing PDF into a div.
From what I can tell the developers simply removed the option, didn't upgrade the docs, and are recommending to hard code the locale in viewer.js (which to me, kind of defeats the point).
I'm hoping someone can point me in the correct direction, and possibly help others who come across this.
For anyone looking to just get this working (until a better answer comes along), heres a fix;
Find the method "_initializeL10n" in viewer.js (line 552 in v2.5.207);
async _initializeL10n() {
this.l10n = this.externalServices.createL10n({
locale: _app_options.AppOptions.get("locale")
});
const dir = await this.l10n.getDirection();
document.getElementsByTagName("html")[0].dir = dir;
}
Change it to this;
async _initializeL10n() {
var hash = document.location.hash.substring(1);
var hashParams = (0, _ui_utils.parseQueryString)(hash);
this.l10n = this.externalServices.createL10n({
locale: ('locale' in hashParams) ? hashParams['locale'] : _app_options.AppOptions.get("locale")
});
const dir = await this.l10n.getDirection();
document.getElementsByTagName("html")[0].dir = dir;
}
This takes the code we need from the old version and gets #locale= working.
I hope to be told the correct way of doing it at some point.
I tried to edit document via couchbase console, and caught this warning message:
Warning: Editing of document with size more than 2.5kb is not allowed
How can I increase max editing document size?
You can raise the limit or disable completely on version 2.2:
To raise the limit;
edit file: /opt/couchbase/lib/ns_server/erlang/lib/ns_server/priv/public/js/documents.js
at line 214:
var DocumentsSection = {
docsLimit: 1000,
docBytesLimit: 2500,
init: function () {
var self = this;
Edit the docBytesLimit variable set to 2500 and increase it to your preferred value.
To disable completely;
You can comment out the conditional statement and return a false value.
At line 362 comment out the statement and return false:
function isJsonOverLimited(json) {
//return getStringBytes(json) > self.docBytesLimit;
return false;
}
Hope this helps.. There are limitations as to how much your WYSYWIG editor can handle. So please be careful and as always editing core files can have negative results. We did it on our system and it works for us.
It seems that the UI code will actually make the request and get the document back, but then refuse to show it if it's too big. So, you can actually just open up the browser developer tools, find the request for the document you want in the network traffic, and the document itself is right there in the response. Copy-paste into a pretty-printer, and you're done.
for Mac OSX, u can edit
/Applications/Couchbase Server.app/Contents/Resources/couchbase-core/lib/ns_server/erlang/lib/ns_server/priv/public/js/documents.js
Couchbase console is here to help you, but when you deal with large data it is better to use a SDK and modify your document using some code. You can find all the SDKs here:
http://www.couchbase.com/develop
Is is possible with your environment?
If i read the code correctly it's seems like a hard code value in the UI code http://review.couchbase.org/#/c/22678/2/priv/public/js/documents.js
On Windows in Couchbase Server 3.0.3 this file is located at
C:\Program Files\Couchbase\Server\lib\ns_server\priv\public\js
As of Couchbase 4.5 you have to modify the app.min.js file not the documents.js. To permanently fix try:
sed -i 's|return getStringBytesFilter(json)>docBytesLimit;|return false;|' /opt/couchbase/lib/ns_server/erlang/lib/ns_server/priv/public/ui/app.min.js
Since couchbase 4.5 you need to update the following app.min.js file to view the documents larger than 2.5Kb.
vi /opt/couchbase/lib/ns_server/erlang/lib/ns_server/priv/public/ui/app.min.js
search for the word docBytesLimit within the file using below command. This will show you all the occurrences in highlighted color.
/\<docBytesLimit/>
Find the text constant("docBytesLimit",256*1024) within above occurrences and replace the 256 with the value you needed.
Finally restart the couchbase server
Frequently GAS users (me too) do not use the ServerHandler.addCallbackElement method or use in a way which does not cover all controls.
What is a background to have this method at all? Why GAS developers introduced it? Is it simpler to pass all input widgets values to all server handlers as parameters?
The documentation does not provide answers to these questions.
I see the following causes
Adding widgets as callback elements reduces traffic between browsers and GAS servers in case of several handlers which handle different sets of controls. Here is a question. How much traffic it saves? I think maximum a few kilobytes, usually hundreds of bytes. Is it worth, considering the modern internet connections speed, even mobile connections.
A form contains a table-like edit controls with multiple buttons and it is comfortable to handle row elements with the same name. This issue is easily avoided by using tags. See the following example. If the tags are used for other purposes it is not a problem to parse the source button id and extract the row number.
Limits of technology used behind the scenes. If there are such limits, then what are they?
function doGet(e) {
var app = UiApp.createApplication();
var vPanel = app.createVerticalPanel();
var handler = app.createServerHandler("onBtnClick");
var lstWidgets = [];
for (var i = 0; i < 10; i++) {
var hPanel = app.createHorizontalPanel().setTag('id_' + i);
var text = app.createTextBox().setName("text_" + i);
text.setText(new Date().valueOf());
var btn = app.createButton("click me").addClickHandler(handler);
btn.setTag(i).setId('id_btn' + i);
var lbl = app.createLabel().setId("lbl_" + i);
hPanel.add(text);
hPanel.add(btn);
hPanel.add(lbl);
lstWidgets.push(text);
lstWidgets.push(btn);
vPanel.add(hPanel);
}
// The addCallbackElement calls simulate situation when all widgets values are passed to a single server handler.
for (var j = 0; j < lstWidgets.length; j++) {
handler.addCallbackElement(lstWidgets[j]);
}
app.add(vPanel);
return app;
}
function onBtnClick(e) {
var app = UiApp.getActiveApplication();
var i = e.parameter[e.parameter.source + '_tag'];
var lbl = app.getElementById("lbl_" + i);
lbl.setText("Source ButtonID: " + e.parameter.source + ', Text: ' + e.parameter["text_" + i]);
return app;
}
Great Question.
"How much traffic it saves?" I don't think we know yet, but I expect it will get more efficient over time. Here is another discussion on performance. Only extensive testing and improvements from Google will really allow us to identify best practices, for now all I can say is that ClientHandlers are clearly going to be better than ServerHandlers whenever possible.
As JavaScript developers I think we are predominantly use to doing stuff client-side, then we think of PHP/ASP as server-side tools. My understanding so far is that our GAS code is actually running both client and server side (at the very least it's calling server side functionality) but it sure seems like there's more going on server-side than we realize, and on the client-side this seems to result in somewhat "compiled" code. I kinda recognize some of this multi-tier deployment from my Java experience.
Since there are a lot of ways of doing the same thing, Google can take advantage of the fact that our code is not directly interpreted (by either side) to do things that would not necessarily make sense if we were writing the code by hand. This is why I think it will become more efficient than other solutions, eventually but probably not yet. For now I'd suggest steering clear of GAS if you are worried about performance. Maybe just for fun try looking at the source of your client-side Web-Apps at runtime (view source). So in order for them to do things most efficiently, I imagine they will benefit by having us define things in a very high-level way. This gives them the most flexibility in how they interpret our code.
To specifically address your second question I personally think of the Handler Function onBtnClick() as running on the Server-Side, whereas the Tags you refer to (and most of the doGet) would be in the browser's engine on the client-side. I can see how the functionality would be much more flexible (efficient and powerful) on the server-side if they have an idea ahead of time as to how much memory they would need to handle specific events/requests. (Clearly if each getElementById() call was running a separate request, that would be like clicking a link to a new mini-webpage each time.)
So now the question is why can't my handler just automatically create parameters with just the stuff I use in my handler function? The only reason we are asking this question in the first place is because there is some stuff in the UiApp which seems to be available on both ends. The UiApp is already in the scope of both the doGet and onClick but the variables defined in doGet are not, so these values need to be either
explicitly saved like ScriptProperties.setProperty() or
put into the UiApp somewhere with an Id or
explicitly given to the Handler function using addCallbackElement()
Notice how you had to addCallbackElement(lstWidget), because it was not created with an app.create... constructor within the UiApp object. My guess is that GAS is implementing XML compliant SOAP calls to a web-service on the Google end, we may be able to figure this out by really studying the client-side source code. Just to reiterate we could also use setProperty() it does not really matter, or even save them via JDBC and then retrieve them with another connection from within your handler function but somehow the data needs to be passed from the Client to the Server and vice-versa.
From a programming perspective there is a lot of stuff available in the scope of your client-side doGet function that you probably would never want to pass to the server, or there may be functions in the scope of the server-side doClick() with the same name as functions on the client-side but they may actually be calls to totally different library functions maybe even on totally different hardware (even though from the developer's perspective they work the same way).
Maybe the Google team has not yet really decided on how the UiApp really works yet, otherwise they would just force or at least allow us to put everything in there. Yet another observation when we call UiApp.getActiveApplication() based on it's name it does not seem like a constructor, but rather a method that returns a private instance from the UiApp object. (Object being a class that was previously instantiated and supposedly initialized somewhere.) I may not have 100% answered your question but I sure did try, any further insight from the community would clearly be appreciated.
Now I may be straying off-topic but I also imagine the actual product will continue to change as they do more to improve performance in the long-term, and if we still feel like we are writing client-side code as a developer then that is a success for Google. Now please correct me if I have stated anything wrong, I have just recently started using these tools and plan to follow up on this question with more specifics as I learn more but as of right now that is my best interpretation.
If you use a formpanel all the sub elements will be sent to your dopost function. With the button as source. And your UIapp will be cleaned.
If you don't want that use a callback to specify what element and siblings will be sent.
This is how the UIapp is designed.