| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
mesh upload
Tried to add consistent mesh upload retries in the HTTP work but a
combination of bad status choices in the upload service and the
one-shot nature of the upload capabilities means that status
information can be lost. For now, retain the wonderful manual
retry logic. At some future point, we might fix the services or
add application-level retry.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Shrink floater and add a "!" icon in the top left corner.
|
|
|
|
|
|
|
|
feature it replaces. This fixes the crashes reported by Whirly ;-)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OS built viewers
|
|
by an install prior to 3.12
|
|
|
|
|
|
|
|
|
|
|
|
ErrorFetchingServerReleaseNotesURL in panel floater_about
|
|
|
|
Problem involved a 3-way livelock between the main, upload
and decomposition threads. Viewer is shutting down but an
upload is in the 'generate hulls' state. Main thread asks
upload request to discard and spins waiting for it to finish.
Upload thread is in generateHulls spinning waiting for the
decomposition thread to process a mesh request. Decomposition
thread is sleeping waiting for main thread to deliver work
that upload thread has asked the decomposition thread to do.
|
|
|
|
when it has been changed
|
|
overlapping each other in IM conversation after resizing.
|
|
|
